THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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
...
(
...
...
...
)
...
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:
| No Format |
|---|
. 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. h3. 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: {noformat} <a href="#" wicket:id="create"> {noformat} |
The
...
HTML
...
generated
...
at
...
runtime
...
will
...
look
...
something
...
like
...
this:
| No Format |
|---|
} <a href="?wicket:interface=:4:create::ILinkListener:"> {noformat} |
The
...
content
...
of
...
the
...
"href"
...
attribute
...
can
...
be
...
grabbed
...
using
...
the
...
following regex.
| No Format |
|---|
regex: {noformat} "([^"].+:create:[^"].+?)" {noformat} 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. |
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?
| No Format |
|---|
{noformat} <form wicket:id="form"> {noformat} This is exactly the same as handling a link. The HTML generated at runtime will be something like this: {noformat |
The HTML generated at runtime will be something like this:
| No Format |
|---|
} <form action="?wicket:interface=:5:form::IFormSubmitListener:" {noformat} |
And
...
the
...
regex
...
required
...
is exactly the same as handling a link:
| No Format |
|---|
: {noformat} "([^"].+:form:[^"].+?)" {noformat} |
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:
| No Format |
|---|
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: {noformat} <td wicket:id="new"><a href="#">Click Me</a></td> {noformat} Runtime: {noformat} |
Wicket generates some "onclick" javascript at runtime:
| No Format |
|---|
<td wicket:id="new" onclick="window.location.href='?wicket:interface=:4:header:new::ILinkListener:';return false;"><a> <a href="#">Click Me</a></td> {noformat} |
The
...
formula
...
for
...
this
...
is
...
slightly
...
different
...
-
...
single
...
quotes
...
instead
...
of
...
double
...
quotes.
| No Format |
|---|
} '([^'].+: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:
| No Format |
|---|
{noformat} h3. 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: {noformat} <input value="radio43" type="radio" name="myradio" id="long_nested_path"/> <label for="long_nested_path">My Label</label> {noformat} |
You
...
can
...
get
...
the
...
value
...
you
...
are
...
interested
...
in
...
corresponding
...
to
...
the
...
string
...
"My
...
Label"
...
in
...
this
...
case
...
like
...
this:
| No Format |
|---|
} <input value="([^"].+?)".*\n.*My Label {noformat} *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. h3. 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! |
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!