Related Entries

Quick Start: Git for personal use
SVN client over SSH to remote Unix server from Windows
Quick Start Grinder - Part V
Quick Start Grinder - Part III
Quick Start Grinder - Part II

« Quick Start Grinder - Part III
» Quick Start Grinder - Part V

Quick Start Grinder - Part IV

Record, extract, reuse

We will use the recorder that came with Grinder to record a test script.

Parts I, II and III of the series.

Step 1: Start and configure the recorder

Start it by running bin\startProxy.cmd. Change your browser setting to route the data through this proxy. Note that if your setup is behind another proxy, you need to pass -httpproxy command line option to the proxy.

Step 2: Start Recording

When you started proxy, a small Java dialog box would’ve come up. It takes some time to come up and quite possibly is behind your other windows. In that, you can add comments on what you are about to do. These comments are then preserved in the generated code.

So, let us add a comment @@@Getting google search page. Now, go to Google using your browser. After the page loads up completely, add a comment @@@Search for GRINDER. Now, type GRINDER in the search field and hit submit. Wait till the results come back. After the results are loaded, press Stop on the console to exit the recorder.

Look at the batch file to see where exactly are you keeping the generated file. Open it up in an editor. Few things you can notice are below.

Now go deploy the file (not the recorded one, but the modified one from our first script) and test.

You should definitely read the TCPProxy documentation. You can see that the code generator is actually an XSL file. We can write our own XSL to generate the code the way we want to - so that we don’t need to do the manual step above. If you write one, do share it with me:-)

Why is this beneficial? Your __call__ method should be short and sweet and nicely explain the flow you are trying to automate. You may have different transactions that make up one flow. So, if you visualize that first, and write logic for your test, then all you need to do is to record individual transactions and plug that into the __call__ method. Once it is written, for enhancements, usually you might find that it is easier to just go and fix the code rather than re-recording the whole thing. Also, you most certainly will want to parameterize your tests to have some logic - that will mean re-recording will mess things up.