Writing Performance Tests in Grinder using a Framework

by vivin

Here we do two additional things. After creating an instance of LoginTask, we create an array of name-value pairs and assign it to loginCredentials. We then create a new property for this particular instance of LoginTask called loginCredentials, and set the value of that property to the array we just defined. The reason we do this is because we’re going to be refering to this array in our parameterizing method. Then, we actually define the parameterizing method. In the method, we choose a name-value pair out of the array using the current thread number as an index. We then use the username and password in the name-value pair as our login credentials. What we’re essentially doing is modifying the username and password parameters for request number 201 in the appLogin2 method of LoginTask. The neat thing is that you can put whatever logic you want inside the parameterizing method. You could even read from a file if you wanted to.

Finally, here is one more example. It’s a bit more complicated, but see if you can figure out what it’s trying to do. I’m providing a link to it (grinder-frameworked.py) since it’s a little long. The code is commented so that should help :): I hope this demonstrates the power and flexibility of the testing framework. Now you’re ready to write your own tests using this framework! But before that, you’ll need to know how to translate the data from TCPProxy.

Using xmlToJython.pl

xmlToJython.pl is a handy script that I wrote, that translates XML header data from TCPProxy into a Jython class. Before you use it, you need to have TCPProxy return XML data instead of Jython. You will need to create a new shellscript:

#!/bin/bash
. setGrinderEnv.sh
java -cp $CLASSPATH net.grinder.TCPProxy -http $GRINDERPATH/etc/httpToXML.xsl -console > grinder.xml

Then, you’ll need to use xmlToJython.pl to convert the XML file into Jython. The syntax for xmlToJython.pl is this:

xmlToJython.pl input.xml [output.py]

The output file is optional. If one is not provided, the script just outputs to STDOUT. The script requires that the XML::Simple module has been installed. The easiest way to do that is through cpan (a commandline tool to install Perl modules). I’m going to see if I can compile the script into a binary so that you don’t have to jump through hoops to use it.

A few more tips… xmlToJython.pl has a feature that lets you make your generated script a bit nicer to read. In the code samples above, you’ll notice that the methods had nice names like “appLogin1” instead of “page1”, and that the description strings for the tests were actually informative instead of just “GET /somefile.html”. Here’s how you can do that: When you start up TCPProxy, you’ll notice that you can add comments. If you make sure that your very first comment is of the form:

@NameOfTaskClass pageMethodName:Description of Task

Then, your recorded class will be called NameOfTaskClass, your page methods will start with pageMethodName, and your test descriptions will have “Description of Task” prepended to them. Typically you should only need that very first comment since you’re only recording one discrete task.