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