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 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 and is in sync with your script.
Recorded tests are therefore brittle and may break if you add a new link somewhere or insert a step in the middle of the flow. It may not be possible to re-run 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:.+?)"
The interesting thing here is that this is a "generic" regex. If you know the "wicket:id", this will work for any link.
Within JMeter, you can add a "Regular Expression Extractor" post-processor to any requested page in your test script like this. This is how the above regex will look like: (the regex in the screenshot looks a bit different but does the exact same thing, for more information about the difference - look towards the end of this page)
The "$1$" refers to the content matched by the first regular expression that we have surrounded with brackets. In this case 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.
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.
What about forms?
<form wicket:id="form">
The HTML generated at runtime will be something like this:
<form action="?wicket:interface=:5:form::IFormSubmitListener:"
And the regex required is exactly the same as handling a link:
"(.+: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.
Links nested within other HTML tags
There is one more corner case we need to consider. The wicket Link class allows you to use non-anchor HTML tags as links, for e.g. a TD tag. So if you have:
<td wicket:id="new"><a href="#">Click Me</a></td>
Wicket generates some "onclick" javascript at 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:.+?)'
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!
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
You can easily submit the value of the "myradio" parameter in the next GET or POST request by using a JMeter variable (e.g. ${myradio})
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.
Ajax (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 let me know (Peter Thomas) or inform the Wicket users mailing list or better still, please update this wiki page. Thanks!