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

Compare with Current View Page History

Version 1 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 you would always like to do 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:">
  • No labels