views:

90

answers:

3

Is there a way to modularize JMeter tests.

I have recorded several use cases for our application. Each of them is in a separate thread group in the same test plan. To control the workflow I wrote some primitives (e.g. postprocessor elements) that are used in many of these thread groups.

Is there a way not to copy these elements into each thread group but to use some kind of referencing within the same test plan? What would also be helpful is a way to reference elements from a different file.

Does anybody have any solutions or workarounds. I guess I am not the only one trying to follow the DRY principle...

A: 

You can't do this with JMeter. The UI doesn't support it. The Workbench would be a perfect place to store those common elements but it's not saved in JMX.

However, you can parameterize just about anything so you can achieve similar effects. For example, we use the same regex post processor in several thread groups. Even though we can't share the processor, the whole expression is a parameter defined in the test plan, which is shared. We only need to change one place when the regex changes.

They are talking about saving Workbench in a future version of Jmeter. Once that's done, it's trivial to add some UI to refer to the element in Workbench.

ZZ Coder
That's sad :-( In our case we are starting some asynchronous background job via the GUI of the webapp. The only way to find out whether the job is finished is polling the database via a jdbc request. This is done in a while controller, which is more than a one liner that could maybe imported as a parameter.
jens
This is why we use Grinder and JMeter at the same time. JMeter is good for simpler tasks but Grinder is more powerful for things like this.
ZZ Coder
+1  A: 

I think this post from Atlassian describes what you're after using Module controllers. I've not tried it myself yet, but have it on my list of things to do :)

http://blogs.atlassian.com/developer/2008/10/performance_testing_with_jmete.html

Jared

JaredQ
A: 

Module controllers are useful for executing the same samples in different thread groups.

It is possible to use the same assertions in multiple thread groups very easily.

At your Test Plan level, create a set of User Defined variables with names like "Expected_Result_x". Then, in your response assertion, simply reference the variable name ${Expected_Result_x}. You would still need to add the assertion manually to every page you want a particular assertion on, but now you only have to change it one place if the assertion changes.

BlackGaff