ratacolita commented on issue #6006:
URL: https://github.com/apache/jmeter/issues/6006#issuecomment-2854479994
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
