According to the project's website, the primary target users for The Grinder are "people who understand the code that they're hitting - it's not just a 'black box' with a set of associated response times. Since tests can be coded - and not simply scripted, programmers get to test interior tiers of their application and not just response time via the user interface." The main new features of The Grinder 3 are:
- Support for the Jython scripting engine used to execute test scripts.
- New distribution packaging consisting of separate source and binary zip files.
- HTTP tests can now be directed through an HTTP proxy and other changes.
In an interview with InfoQ, The Grinder project lead Philip Aston shared some background related to the technical decisions that drove the new release features and provided more background about The Grinder. Aston started by explaining the reason for adding scripting support:
The Grinder 2 was popular, but had an extremely limited script format for HTTP testing based on a properties file. I introduced dynamic scripting to allow branching, looping, and custom validation in HTTP test scripts. The script language also has the huge advantage of allowing other types of testing directly from the script, without requiring a custom plug-in.
Aston also gave some insight and interesting history in regards to why Python was chosen as the scripting language vs. using Java for writing test scripts or other scripting languages with JVM support:
I ruled out Java as a scripting language because a goal of The Grinder 3 is to be as easy to use for HTTP testing as The Grinder 2. Separate compilation cycles, fiddling with class paths, and so on, would get in the way of this. That being said, Jython has first class integration with Java, and Java code can easily be tested (see the many examples in the script gallery).
I began working on The Grinder 3 in 2001 when Jython and Groovy were the only horses in the JVM scripting town, so I didn't need to think too hard. Jython has proven to be a good choice for The Grinder. Python is easier than most languages for people to pick up for occasional use. Many users of The Grinder are not Java experts, and simply want to make minor modifications to recorded scripts. On the other hand, Python is a powerful tool for developers who want to use The Grinder for more advanced scenarios; and Jython allows existing Java libraries to be mixed in at will.
The discussion continued with Aston sharing details about TCPProxy - a proxy process that can be placed in a TCP stream, such as the HTTP connection between a browser and a server. Aston mentioned that TCPProxy can record test scripts in Python and identify dynamic variables in URL parameters and forms. He added that "users typically start with a recorded script, then modify it to include/change the user account and other application data that is used, or merge the script with others to generate load covering a mixture of scenarios". Once set up, the test scripts can be controlled and monitored through The Grinder Console.
Version 3 dropped support for a number of settings in the grinder.properties file associated with the prior release as these configurations can now be set directly in the test scripts. He explained what would be the recommended transition path for test scripts written for The Grinder 2:
The Grinder 3 ships with an example script that can interpret a Grinder 2 properties file, but I would recommend re-recording the test script. Scripts can be recorded with the TCPProxy and then replayed in much the same way they could with The Grinder 2. With The Grinder 2, the only way to alter or extend the behavior of the script was to write a plug-in, or in extreme cases, modify The Grinder itself. With The Grinder 3, pretty much anything is possible within the test script itself.
The interview concluded with Aston mentioning that the recent appearance of 3 related projects -- Grinderstone, webFlange and Grinder Analyzer -- finally convinced him to remove the beta label from The Grinder.