skip to content

Would you standardise a team's JMeter JSR223 elements on inline Script text or on Script Files?

level: principalimportance: should knowfreq 38%

answer

  1. One choice changes four other things
  2. Reviewability against self-containment
  3. One form is always compiled, one is conditional
  4. Only one form gets placeholder substitution

basics

~20 s

There is no single right answer. Script Files are reviewable and always compiled; inline text keeps a plan self-contained and is the only form JMeter substitutes variables into. Pick one rule and write it down.

solid answer

~50 s

The two forms differ in more than taste. A **Script File** is a path, so the code lives in a real file that can be reviewed, diffed and unit-tested; JMeter compiles and caches it whenever the engine allows, keyed on path and last-modified time; and its contents are never passed through variable substitution. **Inline Script** text keeps everything in the `.jmx`, so a plan is self-contained, and it is the only form where `${...}` is resolved — but that substitution is what freezes into a cached compiled script, and the code ends up as XML-escaped text in a `<stringProp>`. A defensible rule is: anything longer than a few lines, or shared by two elements, goes in a file; a one-liner may stay inline. What matters more is that the choice is uniform and that both forms take input through bindings, not `${}`.

go deeper

for a junior

You are not expected to set this policy. Know that both forms exist and that a file overrides inline text when both are filled in.

for a middle

Be able to list the concrete differences - substitution, caching, cache key, portability - rather than arguing from taste.

for a senior

Give a rule with a threshold and defend it, and name what the rule costs: placement, shared ownership and validating a shared script against every plan that uses it.

for a principal

Own the standard across teams and the migration to it, including the one non-negotiable part: varying values arrive through bindings so compilation caching stays safe to leave on.

## What actually differs | | Inline `Script` text | `Script File` | |---|---|---| | Where the code lives | inside the `.jmx`, as an XML-escaped `<stringProp>` | a separate file; the plan stores only the path | | `${...}` substitution | yes, on every execution | never — contents are passed to the engine verbatim | | Compilation caching | only when the checkbox is not `false` | always, when the engine is `Compilable` | | Cache key | MD5 digest of the script text | language + absolute path + last-modified time | | Reviewability | a diff of escaped XML | an ordinary source diff | | Portability | the plan is self-contained | every JVM that runs the plan needs the file readable at that path | A relative path in the `Script File` field is resolved against the `user.dir` system property, which is worth knowing before you decide what "the path" means for your team. ## The case for Script Files - **They are code, and can be treated as code.** Review, editor tooling, static checks and unit tests all work on a `.groovy` file and none of them work on an XML attribute. - **Caching is unconditional.** You do not have to remember a checkbox, and because the key includes the last-modified time, editing the file is picked up without restarting JMeter. - **The substitution trap cannot happen.** Since JMeter never substitutes into file contents, no cached compilation can freeze a value. - **Reuse is real.** Several elements can point at one file, and they share a single cache entry. ## The case for inline text - **One artefact.** The plan is the whole test. Nothing to package, nothing to place on the machine before a run, no path to get wrong. - **The GUI is the editor.** For a two-line script, opening an external file is friction that buys nothing. - **`${...}` works.** Occasionally the clearest expression of a value really is a plan-level reference — at the price of either clearing the cache checkbox or accepting the first-substitution freeze. ## A workable rule 1. **A file by default** for anything a reviewer would want to read: more than a handful of lines, anything doing crypto, parsing or arithmetic, anything used by more than one element. 2. **Inline only for trivia** — a single assignment, a log line, a flag flip — and never with a `${...}` reference in it. 3. **Never both fields on one element.** A run uses the file and ignores the text, but the GUI's compile check does the opposite, so an element with both is checked against code that never executes. 4. **One language.** Groovy is the bundled default and the one that compiles; mixing engines across a team's plans buys nothing and costs everyone a second thing to know. ## What you have to decide either way Going to files does not end the discussion, it moves it. You now have to decide where the scripts live relative to the plans, whether paths are relative or absolute, who owns the file when two plans share it, and how a change to a shared script is validated against every plan that uses it. Those questions have no universal answer, which is why the honest response to this interview question is a rule plus its cost, not a preference. The one part that is not a judgement call: whatever varies per execution enters the script through the bound context, not through `${}` in the source. That holds for both forms, and it is what keeps compilation caching safe to leave on.

  • What breaks first when a team moves JMeter JSR223 scripts out of the plan and into files?
    Placement. The plan stores a path, not the code, so every JVM that runs the plan must be able to read the file at that path, and a relative path resolves against the `user.dir` system property rather than the plan's directory. Deciding the convention for that path is the first real cost of the move.
  • Would you allow a JMeter JSR223 element to have both a Script File and inline Script text?
    No. At run time the file wins and the inline text is dead code, but the GUI's Compile JSR223 Test Elements action compiles the inline text whenever it is non-empty. So the element is validated against the half that never runs, which is a trap worth banning outright rather than documenting.
  • If a team standardises on Script Files, does the 'Cache compiled script if available' checkbox still matter?
    Not for those elements. The file branch never reads the checkbox: when the engine implements `Compilable` the file is compiled and cached regardless. The checkbox only governs inline script text, so a file-only standard removes one setting people have to reason about.

saying these in an interview costs you the question

  • Answers with a preference and no tradeoff
  • Claims script files are always faster to execute
  • Forgets that a plan stores the path, not the file
  • Assumes ${} substitution works the same in both forms
  • Ignores that reviewing scripts inside a .jmx is the real cost