jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <>
Subject User defined variables at ThreadGroup scope
Date Tue, 14 Feb 2017 01:13:26 GMT
I am converting some code from the eggPlant test tool we've been using, which effectively supports
properties or variables (essentially everything is a variable in its context) at the thread
group (TG) level.

It's a pretty useful feature, as typically I set up default props/vars for a test, then override
them at the TG level.

Currently UDV are implemented as Arguments, which when processed at the start, are added to
the JMeterContext in the PreCompiler

        if (node instanceof TestPlan) {
            ((TestPlan)node).prepareForPreCompile(); //A hack to make user-defined variables
in the testplan element more dynamic
            Map<String, String> args = ((TestPlan) node).getUserDefinedVariables();
            JMeterVariables vars = new JMeterVariables();
        if (node instanceof Arguments) {
            Map<String, String> args = ((Arguments) node).getArgumentsAsMap();

I'm trying to figure out whether I should implement support for this in JMeter and wondered
if there was ever a demand for this.

As I see it, it would require the ability to define variables at the thread group, similar
to the current UI at the TestPlan level and would require a similar implementation to the

        if (node instanceof TestPlan) {

code to test for instance of ThreadGroup after the Arguments test, so that thread group variables
took precedence over (UDV) Arguments defined varaibles.

There would be some additional UI work for the TG definition (as per the TestPlan definition)
and some loading glue to parse the Arguments from the TG, but as this all happens at the tree
parsing level, I don't think there would be any downstream considerations, as the last set
of variables would then take precedence over all the others.

Any thought or advice?  If this is not too hard I'd be happy to provide a patch back.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message