How would you decide between a JMeter GUI-authored plan and a scripted load runner for a team?

## Refuse the question as usually posed "GUI or code?" is a preference dressed as an engineering question, and the first thing a lead should do is replace it with something decidable. The decidable version is: **which of Apache JMeter 6.0.0's five properties does this team actually pay for, and what does each cost us over the next two years?** Everything below is a fact about JMeter. Nothing below narrates how a rival tool works, because that is not this argument's to make. ## The five axes 1. **Who authors and maintains the plan.** JMeter's plan is built in a GUI and stored as a `.jmx` XML file. That is a real capability: a tester who does not program can build and change a load run unaided. It is also a real cost, because the artifact of record is machine-written rather than human-written, which makes review and concurrent editing more expensive. 2. **Protocol scope.** The 6.0.0 download samples HTTP, JDBC, JMS in three shapes, FTP, LDAP, SMTP and mail, TCP, OS process, JUnit, Bolt and more. For a suite that genuinely spans transports, this decides the question on its own. For an HTTP-only suite, it is worth precisely zero and should be dropped from the comparison rather than repeated. 3. **How the pipeline reaches a verdict.** JMeter 6.0.0's command-line options cover the test file, the result log, property injection, remote engines and report generation — and stop there. **No option fails a run because a latency or error-rate threshold was crossed**, and the exit-code settings in `jmeter.properties` govern JVM shutdown rather than test outcomes. A team adopting JMeter is signing up to build and own that gate; how it is built is the JMeter tree's own threshold-enforcement topic. 4. **The load shape you need.** The stock `Thread Group` is a closed model, so its `Number of Threads (users)` field caps concurrency rather than arrival rate. The Apache answer is the `Open Model Thread Group`, core since 5.5 but still marked experimental at 6.0.0; the mature alternative is the third-party jmeter-plugins Custom Thread Groups, which your build must install. 5. **Injector cost.** Each virtual user is an operating-system thread, so the user count is sized against the injector and scaled by adding injectors. ## A worked decision Take a team weighing an existing JMeter plan against rewriting on a scripted runner. Score the axes rather than debating them: | Axis | Points to JMeter when | Points away when | |---|---|---| | Authorship | testers without a programming language own the suite | the suite is owned by engineers who already write in that language daily | | Protocol scope | the suite touches databases, queues or mail as well as HTTP | scope is HTTP only | | Pipeline verdict | a gate already exists and works | the pipeline needs a threshold gate out of the box | | Load shape | fixed concurrency is the shape you actually test | rate-shaped load is central and must not rest on an experimental component | | Injector cost | concurrency is modest, or injectors are cheap | very high concurrency from few machines is a hard requirement | Two rules keep the exercise honest: - **Score what you use, not what exists.** A capability nobody exercises is not a reason. - **Price the migration, not just the destination.** A working suite carries accumulated correctness — assertions, data, tuning — that a rewrite discards and re-earns. Whether to rewrite a harness at all is its own subject, owned by the test-automation foundations; the lead's job here is to insist the question is asked rather than assumed. ## The judgement most teams get wrong Most tool migrations in this space are argued on the authoring experience — the axis with the loudest opinions and the smallest long-run effect — while the verdict axis, which genuinely changes what the pipeline can do, is discovered afterwards. Invert that. Decide the verdict and protocol axes first, because they are objective; decide authorship next, because it is about the people you actually have; and let injector cost decide only when the concurrency requirement is genuinely near the limit of what you can afford to run. ## Where the other side of each axis is taught State JMeter's surface and cede the rest by name: a scripted runner's exported configuration object to `dev-k6-options-options-object`, its executor named as a string to `dev-k6-executors-arrival-executors`, its native threshold expression and breach exit code to `dev-k6-verdict-threshold-syntax` and `dev-k6-verdict-exit-codes`, its compiled binary add-ons to `dev-k6-runtime-extensions`, a JVM simulation DSL to `dev-gatling-dsl-jvm-entry`, its five SDK packagings to `dev-gatling-dsl-node-packages`, its injection vocabulary to `dev-gatling-injection-registration`, and its post-run assertion chain and exit signal to `dev-gatling-outcome-assertion-grammar` and `dev-gatling-outcome-exit-signal`. Quoting a rival's syntax is not what makes this answer strong; being specific about JMeter is.