You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Limitations of recorded JMeter tests

The main challenge when creating a Jmeter script for a Wicket application is that the links are dynamic. Of course, this is a very good thing from a security point of view. It is possible to record a test using JMeter (pdf link) but when running a recorded test against a Wicket application you have to be careful about recording and playing back tests so that that the test begins with a freshly created session. This is required to ensure that the number that appears in the "wicket:interface" parameter in the URL starts from 1.

Recorded tests are therefore brittle and will break if you add a new link somewhere or insert a step in the middle of the flow. It would not be possible to re-try running sections of your test while keeping your application runnning, which is desirable when developing a script.

Recording can help a lot for e.g. to understand what exactly is being POST-ed when you have complex form submissions etc. but described below is an approach using JMeter regular expression support to arrive at stable and repeatable test scripts for Wicket applications.

Regular Expressions based approach

JMeter can parse HTML responses and extract pretty much anything you want using regular expressions. By the way, this is an interesting alternative to writing functional tests on web-applications - because you can assert for expected results this way.

So the key to testing a Wicket application is to derive the URL that has to be used in the next step from the HTML response for the previous step. For example, consider a normal link of the form:

<a href="#" wicket:id="create">

The HTML generated at runtime will look something like this:

<a href="?wicket:interface=:4:create::ILinkListener:">

The content of the "href" attribute can be grabbed using the following regex:

"([^"]+:create:[^"]+)"

Within JMeter, you can add a "Regular Expression Extractor" listener to any requested page in your test script like this. This is how the above regex will look like:

The "$1$" refers to the content matched by the first regular expression that we have surrounded with brackets. Here there is only one bracketed expression.

So we take the value that we get and put it into a variable called "nextUrl"

Using this in the next step of the script is easy as shown below:

Just append ${nextUrl} to the base path of your Wicket app. That's it!

If you have some deeply nested components you can easily use the resulting Wicket path, e.g. "table:row:5:link". The good thing is that this path normally does not change.

<form wicket:id="form">

This is exactly the same as handling a link. The HTML generated at runtime will be something like this:

<form action="?wicket:interface=:5:form::IFormSubmitListener:"

And the regex required is:

"([^"]+:form:[^"]+)"

Using this is almost the same as a link but this time we set the request method to POST and we also provide the expected request parameters.

There is one more corner case we need to consider. The wicket Link class allows you to nest an anchor tag within some other HTML tag for e.g. a TD tag. So if you have:

<td wicket:id="new"><a href="#">Click Me</a></td>

Runtime:

<td wicket:id="new" onclick="window.location.href='?wicket:interface=:4:header:new::ILinkListener:';return false;">
<a href="#">Click Me</a></td>

The formula for this is slightly different - single quotes instead of double quotes.

'([^']+:new:[^']+)'

Complex Regex Matching Example

Sometimes you have a list of checkboxes and it may turn out that the "value" attribute being generated by Wicket is dynamic. I guess that a way to avoid having the "value" dynamic is to provide an IchoiceRenderer where the getIdValue() is predictable instead of being generated by Wicket.

Anyway, the problem is that you want to figure out the right value to submit as part of a form POST.

So if the generated HTML looks like this:

<input value="radio43" type="radio" name="myradio" id="long_nested_path"/>
<label for="long_nested_path">My Label</label>

You can get the value you are interested in corresponding to the string "My Label" in this case like this:

<input value="([^"]+)".*\n.*My Label

Tip: Paste the browser HTML source into some text editor that supports regex searches (like Textpad) and then some trial and error will narrow down the regex that fits your requirement.

Conclusion

If you know the "wicket:id"s, creating repeatable JMeter tests for Wicket apps could be easier than creating them for normal web applications!

TODO: I have not yet tried to test any Ajax functionality with this approach. However I think that if you record a JMeter test involving Ajax requests and analyze the requests, you should be able to easily derive the steps and regular expressions required. If you have any success with this, please inform me or the Wicket users mailing list or update this page. Thanks!

  • No labels