Virtual Browser Tutorial #3:
Debugging Test Cases

This tutorial shows a little about what happens when the test case doesn’t do what you think it should be doing.  The test case is making a comment on a blog post, but the WordPress logic won’t allow two identical comments on the same post.

1. Record Test Case

First start recording by clicking on the red record button:


Pick a browser, and navigate to and login as before using “demo” and “p@perdoll”.

Screen Shot 2014-02-25 at 1.58.25 PM


Navigate back to and scroll down for the comment field.  Fill out the field as shown below:

Screen Shot 2014-07-08 at 12.20.37 PM

Click on the Post Comment button, and then click on the black stop recording button:

Screen Shot 2013-10-01 at 3.56.52 PM

Once the recording is finished, it will show up in the Navigator Tab:


2. Replay Test Case

The next step is to replay the test case and see how it works.  The problem is that WordPress contains a method to reject identical comments. Luckily, Load Tester will detect the problem and give you a head’s up comparison so you can see the error: “duplicate comment detected”.

On Windows a head’s up display will appear showing that the website is now giving a “duplicate content” error instead of allowing the post like it did when recorded.


On Mac OSX the error looks like this:

Screen Shot 2014-03-02 at 5.46.49 PM

To view the error on OSX click OK, go to the Errors Tab, and right click on the error, selecting Transaction Compare->Response Content.


A window will appear comparing the replay HTML to the original:


Before editing the test case to fix this issue, you’ll want to click on the “back button” to view the original test case, not the replay.


The solution is to configure the test case so that each comment is unique.  To customize the comment field,  first select the web page with the comment form.  In the sample test case of the same time, the form is in the second web page from the top:

Screen Shot 2014-03-02 at 5.53.37 PM

The web page will be rendered below in the Fields Tab, where you can scroll down and find the the comment field where “What’s up, Doc” was original entered.  You then just double-click on “What’s Up, Doc?” to bring up the editor.


When the Edit Field dialog comes up, change the datasource to Concatenation. Then add press the green ‘+’ button to add a Date/Time datasource. Note that you may need to resize the dialog to see the ‘+’ button on the right.

Edit Field dialog screenshot

The above shows two data sources will be used for this comment field. The second is the current date and time, which will randomize the comment enough so that the test doesn’t trigger identical comment errors.  The first data source the original text constant. Alternatively, you could make the comment unique by reading it from a dataset of comments.

Click OK and then run the replay again.  The comment will now be unique and the error is gone.

3. Load Test

Click on the Load Test button to create a Load Configuration:


Start the load test and notice that errors are starting to show up in the Errors Tab. Note that in this case “errors” means a problem with the test case, not a software bug.


To see the error right click on the first one, and select Transaction Compare->Visual Compare:


The compare window will clearly show that WordPress has thrown up a message that didn’t occur in the recording.  What’s happening is WordPress has a built-in mechanism to prevent anonymous users from putting in comments too quickly, probably to deter spambots.


To fix this issue with the test case, the solution is to follow the instructions from Tutorial #2 so that each virtual user logs in with a unique username and password.


Leave a Reply