Now expansion of properties works well. I gave up overwriting
ProjectHelper's ElementHandler to construct WebTest objects and simply
make clones from Task.getRealThing().
However, there are many race conditions when executing WebtestTask
returned by Task.getRealThing() from several threads. WebTest is
claiming empty or null attribute values. I tried making them ThreadLocal
but without success so far...
Any help would be appreciated.
Hi Immo,
the desired test script example would exactly look like a normal
WebTest except the header and footer as mentioned e.g.
<invoke url="..." />
<clickLink label="..." />
<verifyText text="..." />
...
Several such test script pieces will be assembled to the whole test.
The complete WebTest is then wrapped by a JMeter testplan.
Hope that makes things clearer?
Hi Stefan,
That's really tremendous work; thanks for undertaking it. Will you be
producing some example test scripts that exploit these new features?
These would make it easier to understand how to get the best out of
your efforts.
I'm not actually using WebTest or JMeter at this moment, but a
project that may be about to start will have such requirements.
Best regards,
Immo
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan Frenzel
Sent: 22 July 2009 19:28
To: [email protected]
Subject: [Webtest] WebTest properties and JMeter integration
Hello list,
I've begun integrating WebTest in JMeter. It works. However, there
are a few limitations e.g. static and dynamic properties (see below).
But first I want to introduce you in the procedure getting my WebTest
integrated.
An user can write or capture (WebTestRecorder) several pieces/modules
of a WebTest in XML format (XML entities) without taking care of the
Ant/WebTest overhead (<project>, <target>, <webtest> etc.). Then he
or she can start JMeter, add a WebTestSampler, add/order/enable those
modules and run the test according to JMeter's ThreadGroup
parameters. (WebTest configurations (<config>) can be defined in a
property file as well as in a JMeter WebTestDefaultConfiguration
testelement.)
How does it work behind the scenes? First of all, the XML entity
inputs must be assembled (String concatenation) and the Ant/WebTest
"overhead" as mentioned above must be added.
Then we have to initialize an Ant Project object, give it a
ProjectHelper reference and let it parse our XML string. Because Ant
uses SaX parsing we need to overwrite its ElementHandler's
onStartElement() and onEndElement() methods in order to create and
link WebTests objects. For example if onStartElement() gets a
<invoke> tag, we have to create an InvokePage object (via
Class.newInstance()) and add it to the WebtestTask object and so on.
After that the WebtestTask object is passed to the WebTestSampler.
But unfortunately the WebtestTask object isn't thread-safe and cannot
be reused several times (because of destroyed contexts, etc.) from
the WebTestSampler sample() method called by each JMeterThread. To
solve this issue I added a clone() method to WebtestTask which
ensures that each JMeterThread uses a deep copy of WebtestTask to
execute(). That's it.
What do you think about this? In my opinion it's dirty, but I don't
know how to do it alternatively. Any ideas?
My problem is that many WebTests need static (Ant) or dynamic
(WebTest) properties which are created by <property>, <storeProperty>
or something else. I saw that in the internals of WebTest there is a
WebTestPropertyHelper which extends Ant'S PropertyHelper. Also it
seems like this WebTestPropertyHelper is added to the Project as a
reference. However, the replaceProperties() methods are never called
when executing the execute() method at WebtestTask (which delegates
to the execute() methods of its steps). The result is that no
properties get evaluated and the steps which follow have something
like "${}" or "#{}" in their attribute values.
Do you have any suggestions which can solve this problem? What about
RuntimeConfigurable and maybeConfigure()?
Thank you in advance.
Greets, Stefan.
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
