Writing Performance Tests in Grinder using a Framework

Although not useful by itself, the Task class does define some important methods and properties:

Class Variables

In Python, properties defined at the top of the class are called Class Variables. They are different from Instance Variables in the sense that they are shared between all instances of a class. The numberOfTasks property holds the number of Task instances that have been instantiated. The reason we need to maintain this property will become clearer later.

Constructor

__init__ is the constructor for the Task class. Here we initialize a few instance properties. The first property is the urlDict property, which maintains a dictionary of unique URLs. If you'll remember, when I talked about the structure of a test-script, I mentioned that the recorder keeps track of unique URLs that it encountered during the recording process. It then used the URLs and headers to create request objects. In a typical recorded-script, the URLs are simply defined as global variables within the script. Here, they are maintained as key-value pairs with the urlDict dictionary.

The next property is the parameterizingMethods property. This property is pretty important since it is what allows us to parameterize requests. I won't go into too much detail; for now just realize that it keeps tracks of methods we use to parameterize our requests.

At the end of our constructor, we increment the value of numberOfTasks by one, because as I mentioned before, this property keeps track of the number of instances of this particular class, that have been instantiated.

Accessor methods

The Task class has three self-explanatory accessor-methods which are getUrlDict, getUrl, and getParameterizingMethodFor. The first method returns the entire urlDict dictionary, while the second returns a particular URL (identified by a supplied key) from the urlDict dictionary. The third method returns the parameterizing method for a particular (supplied) key.

Mutator methods

The _Task_ class also has three self-explanatory mutator methods which are setUrlDict, setUrl, and setParameterizingMethodFor. The first method sets the urlDict property to the one supplied, while the second one sets the value of a particular URL within the urlDict dictionary (identified by a supplied key) to the supplied value. The setParameterizingMethodFor method sets the parameterizing method for a particular (supplied) key.

Utility methods

The _Task_ class has two utility methods. The first one, callParameterizingMethodFor, calls the parameterizing method identified by the supplied key. The second method, instrumentMethod is quite similar to the instrumentMethod method in a typical recorded-script. The only difference is that there is no default argument, because we don't need one in this case (instrumentMethod is a class method now, as opposed to a global method).

Now that we've gone over the base class, let's take a look at a class that has been derived from the Task class so that all of this makes a bit more sense. While going through it, compare it to the structure of a typical recorded test-script. You will notice a few similarities.
Note: In the following code you'll notice that the framework is called torqueo. I called it that because the word means "to twist, curl, rack, torture, torment, distort, or test" in Latin. I think that accurately describes what we're trying to do in performance testing. Yes, I'm a dork.