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();
replacer.setUserDefinedVariables(args);
JMeterVariables vars = new JMeterVariables();
vars.putAll(args);
JMeterContextService.getContext().setVariables(vars);
}
if (node instanceof Arguments) {
((Arguments)node).setRunningVersion(true);
Map<String, String> args = ((Arguments) node).getArgumentsAsMap();
replacer.addVariables(args);
JMeterContextService.getContext().getVariables().putAll(args);
}
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.
Cheers
Antony