Support ${...} for TestElement.enabled property

[vlsi]

Use case

It might be helpful to disable some of the bits in the test plan when launching the script from the commandline.

For instance:

• Exclude some of the thread groups
• Exclude some of the listeners (e.g. saving the responses)

Possible solution

Move enabled checkbox to the common UI side by side with name, comments.

Possible workarounds

No response

JMeter Version

5.5

Java Version

No response

OS Version

No response

[ratacolita]

Hi @vlsi,

I've been thinking about the use case covered in issue #6006 (Support ${...} for TestElement.enabled property) and had an idea for a complementary feature that could offer even more powerful dynamic control over test plan elements from the command line: using XPath expressions.

While property-based toggling is great for pre-defined variations, there are scenarios where more complex, ad-hoc selection of elements for enabling/disabling is needed. For example:

• Disabling all elements of a certain type within a specific Test Fragment.
• Enabling only a subset of Thread Groups whose names match a pattern.
• Targeting elements based on their hierarchical position or specific attribute values, especially when names might be duplicated or not suitable as unique identifiers for property flags.

My proposal is to introduce command-line options like:

• --xpath-enable <xpath_expression>
• --xpath-disable <xpath_expression>
• (Optionally) --xpath-set-property <xpath_expression> <propertyName> <propertyValue> for more general modifications.

How it could work: JMeter, before fully parsing and running the JMX, would:

1. Load the JMX file as an XML document.
2. Apply the given XPath expression to select the relevant TestElement nodes.
3. Modify the enabled attribute (or other specified properties) of these selected nodes.
4. Proceed with the modified in-memory version of the test plan.

Key Benefits:

• Precision Targeting: XPath allows for very granular and precise selection of elements.
• Bulk Modifications: A single expression can target multiple elements.
• Flexibility for Complex Plans: Handles duplicate names and complex structures effectively.
• Reduced JMX Pre-configuration: Less need to pepper JMX files with many individual ${...} properties if the decision to enable/disable is purely a runtime/command-line one based on test structure.

To help users validate their expressions, a "dry run" mode would be invaluable: jmeter --xpath-dry-run test.jmx --xpath-disable "//ViewResultsTree" This would output the JMX as it would be modified, or simply list the elements targeted, allowing users to confirm the selection before execution.

This XPath-based modification could be a powerful tool for CI/CD pipelines, test scripting, and managing complex test plan variations without needing to maintain numerous separate JMX files or overly complex property setups.

Would love to get your thoughts on the feasibility and utility of such a feature, and how it might align with or extend the goals of #6006.

[vlsi]

Well, if we consider something like --xpath-disable, then we probably don't want to tie it to enable/disable only. The use cases might be like "make all ViewResultsTree collect errors only".

At the same time, I think the features (${...} for TestElement.enabled and xpath) are complementary, so they could be developed in isolation (I don't think one feature should wait for another).

[ratacolita]

---

(o) Enable ( ) Disable ( ) Expression : [__________________]

Would it be something like that?