Why is a JMeter .jmx plan harder to review and merge than a scripted load test?

## The artifact under review When a team weighs Apache JMeter 6.0.0 against a scripted load runner, the first objection raised is almost always about the plan file. It is worth stating precisely, because the vague version ("XML is ugly") is not an argument and an interviewer will say so. A JMeter plan is an XML document with a `.jmx` extension, produced by the GUI's save action. The GUI is the authoring tool; the file is its output format. That single fact drives everything below. ## Three concrete review costs 1. **The whole document is re-serialised on every save.** JMeter does not patch the file in place — it writes the plan tree out again. So the diff you review is whatever the serialiser produced, not a minimal edit, and "only this one field changed" is a claim the diff cannot make for you. 2. **The root element carries the writing build's version.** JMeter stamps the `<jmeterTestPlan>` root with `version`, `properties` and a `jmeter` attribute holding the version of the JMeter that wrote it. A team member on an older build who opens and saves the plan produces a change nobody intended. 3. **Meaning lives in the GUI, not in the text.** In a scripted plan, an assertion or a data-driven loop reads as a statement. In `.jmx`, the same intent is a set of XML properties whose semantics come from the element type. A reviewer with the file alone can verify that *something* changed far more easily than *whether it is right*. ## What this actually costs a team - **Review becomes a two-window job.** The diff tells you which elements moved; the GUI tells you what the plan now does. Teams that review `.jmx` well make opening the plan part of the review, not an optional extra. - **Concurrent editing is expensive.** Two people editing one large plan produce conflicts in generated markup, which is unpleasant to resolve by hand and easy to resolve wrongly. - **Blame is coarse.** History tells you a plan changed and who saved it, which is weaker than line-level authorship over a script. ## What JMeter gives you to soften it The complaint is real but not fatal, and a strong answer says how the cost is managed rather than only that it exists: - **Split the plan.** Smaller plan files, and reusable fragments referenced from them, shrink the surface any one save can touch and let two people work without colliding. The fragment and module mechanics are the JMeter tree's own plan-fragments topic. - **Push logic out to script files.** Behaviour written in a JSR223 element and stored in an external script file is reviewed as text, in its own file, with line-level history. That is the JMeter tree's JSR223 topic; the point here is only that it moves reviewable substance out of the XML. - **Standardise the writing build.** Pinning the JMeter version the team authors with removes the restamping noise entirely. - **Externalise the values that change most.** Anything driven by a property or a data file does not need a plan edit to change, so the plan itself stays stable in history. ## Scope of this claim The `.jmx` document format itself — its element grammar and property encodings — is the JMeter tree's own JMX-format topic, and general branching and code-review practice belongs to version control, not to this comparison. What belongs here is exactly the trade this leaf exists to state: JMeter buys you an authoring surface that needs no programmer, and pays for it with an artifact that is machine-written rather than human-written. The reviewable-source-code half of that comparison is taught by the tools that own it, including `dev-k6-options-options-object` and `dev-gatling-dsl-jvm-entry`. ## How to answer it well Say what the file is, name the three costs, then name the mitigations. A candidate who only says "XML is hard to merge" has stated a feeling; a candidate who says "the GUI re-serialises the whole plan and stamps the writing version on the root, so we pin the authoring build and keep plans small" has stated an engineering position.