There are a number of places in which scripting is implemented in the DevTest. We have scripted assertions, script test steps, scriptable data protocol handler and service image match scripts. The provided functionality is effective, and has been recently enhanced to support JSR-223 plug-in scripting languages, but there are additional facilities that would be extremely useful, to improve effectiveness and efficiency, and to enhance this entire area.
Here is a list of what I would like to see in the future:
1. Context-aware code completion
This would show available methods, arguments, variable names and functions while the user is typing
2. Colour-coding script elements
This is already implemented in some scripting engines, but some (e.g.: Groovy) just show raw text on background
3. Script library
When creating scripts, they currently need to be stored in tests - otherwise they are just embedded into the script area where they are created, and are impossible to find in the future. If there was a library of scripts, which could be selected on demand from the dialog in which they are required, we would not need to store code fragments in tests.
Custom test steps
The current UI shows "Scripted assertion". I would find it useful if "Scripted assertion" had list items underneath it, matching each of the scripted assertions already created and stored in the library.
the current UI shows "Match script", with a right-lcick option to insert a sample match script. I would find it useful if the right-click showed a library of match scripts stored in the library.
Data Protocol Handler
The current UI shows a list of data protocol handlers, one of which is "Scriptable Data Protocol". I would find it useful if all created scriptable DPHs stored in the library were shown in this list, perhaps with a marker to note that they are scripted rather than compiled, so they have not been through a QA cycle, so can't be guaranteed to be without memory leaks, performance issues or quality defects.
4. "first-class" scriptable data protocols
Currently, only one scriptable DPH can be used in a virtual service (and it's used before other payload manipulation is done). I would find it useful if multiple scriptable DPHs could be daisy-chained. For example, decode a transport in a scriptable DPH, use a copybook DPH to make arguments from the request, use a scriptable DPH to manipulate sections of the arguments, etc.
5. Further uses of scrips
Scripted data set: I sometimes need to query Excel as a database (select excel_rownum where foreign_key = value), and I currently do this by either exporting the excel file to a database or by using a script step to interact with Excel directly using Apache POI. I would find it useful to have a scripted data set.
Scripted filter: When I need to retrieve lots of properties from a message response, I currently either add lots of filters, or I save the response into a property and then create a scripted step to read the response and perform actions against it. I would find it useful to have a scripted filter, so it looks elegant in my test
6. VSE facilities available when creating a scriptable DPH
As I mentioned earlier, when I create a scriptable DPH, I write it as a scripted test step. There are some methods used in virtual services that aren't implemented in tests (e.g.: lisa.vse.*), so I need to work around these with lots of debugging loops. I would find it useful if all necessary virtual service properties were available to the step where I'm creating the DPH.