skip to content

In a JMeter .jmx, what do stringProp, boolProp, elementProp and collectionProp each hold?

level: middleimportance: should knowfreq 34%

answer

  1. Tag names all end the same way
  2. The name attribute is the field key
  3. Two of them are containers
  4. Numbers are often stored as text

basics

~10 s

They are JMeter's property tags: stringProp a text value, boolProp a true or false value, elementProp a whole nested test element, and collectionProp an ordered list of properties.

solid answer

~50 s

Every field of a JMeter element is written as a child tag named after the property type it holds, with the field key in a `name` attribute: `<stringProp name="HTTPSampler.path">/cart</stringProp>`. `boolProp` carries `true` or `false`; `intProp` and `longProp` carry numbers. `elementProp` is the interesting one — it holds a complete nested test element inline, with its own `elementType` attribute, and is how a Thread Group carries its loop controller or an HTTP Request carries its parameters. `collectionProp` is an ordered, unnamed list whose entries are usually `elementProp` children. Note that a numeric field's tag follows the value, not the field: `ThreadGroup.num_threads` is declared as an integer property, so JMeter 6 writes `<intProp name="ThreadGroup.num_threads">50</intProp>` for a literal and falls back to `<stringProp>` only when the field holds an expression such as `${__P(threads,10)}` — which is the whole reason the field must tolerate text at all. Plans written before JMeter 5.6.3 hold a `stringProp` there even for literals, and a load/save round trip preserves whatever type was loaded.

code

xml · 14 lines
xml
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="POST /cart" enabled="true">
  <elementProp name="HTTPsampler.Arguments" elementType="Arguments">
    <collectionProp name="Arguments.arguments">
      <elementProp name="" elementType="HTTPArgument">
        <boolProp name="HTTPArgument.always_encode">false</boolProp>
        <stringProp name="Argument.name">sku</stringProp>
        <stringProp name="Argument.value">A-100</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
    </collectionProp>
  </elementProp>
  <stringProp name="HTTPSampler.path">/cart</stringProp>
  <boolProp name="HTTPSampler.follow_redirects">true</boolProp>
</HTTPSamplerProxy>

go deeper

for a junior

Recall that the tag says the value type and the name attribute says the field, so stringProp name="HTTPSampler.path" is the path field of an HTTP request.

for a middle

Explain elementProp as a nested element held as a property and collectionProp as an ordered list, and why a numeric field's tag follows the value rather than the field.

for a senior

Show how these shapes make a text diff misleading: positional list entries, opaque keys, and nested elements that read like new ones.

for a principal

Set the expectation that a plan change is reviewed by what it does, not by its XML, because the encoding does not carry the meaning a reviewer needs.

Inside an element tag, every field is one child tag. The tag name says what kind of property it is; the `name` attribute says which field. The alias block in `bin/saveservice.properties` lists them, and every one ends in `Prop`. ## The scalar property tags - `stringProp` — a text value; by far the most common. - `boolProp` — `true` or `false`. - `intProp`, `longProp`, `doubleProp` — numeric values. - `objProp`, `mapProp` — rare, and you will mostly meet them in older plans. A field's tag is not fixed by the field. The Loop Controller is the classic demonstration: type a number into the loop count and the GUI stores a string, giving `<stringProp name="LoopController.loops">5</stringProp>`; tick the forever box and the GUI stores the integer constant instead, giving `<intProp name="LoopController.loops">-1</intProp>`. Same field, different tag, and a diff that looks like two unrelated lines. Many fields that hold nothing but digits still turn up as `stringProp`, and the reason is the same: a `stringProp` can hold a JMeter expression that is resolved at run time, and a typed property cannot. `ThreadGroup.num_threads` and `ThreadGroup.ramp_time` are declared as integer properties, so JMeter 6 writes `intProp` when you type a literal and falls back to `stringProp` when you type an expression such as `${__P(threads,10)}`. Plans written before JMeter 5.6.3 stored these fields as text even for literals, and a re-save only rewrites the element you actually opened — which is why both tags turn up for the same field in the wild. ## The two container tags `elementProp` holds an entire test element **inline**, as a property of its parent, rather than as a child of the parent's paired `hashTree`. It carries a `name` for the field it fills and an `elementType` naming the class of the element inside it: ```xml <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true"> <boolProp name="LoopController.continue_forever">false</boolProp> <stringProp name="LoopController.loops">5</stringProp> </elementProp> ``` `collectionProp` holds an ordered list. It has a `name` but its children do not need one, because their position is their identity: ```xml <collectionProp name="Arguments.arguments"> <elementProp name="sku" elementType="Argument"> <stringProp name="Argument.name">sku</stringProp> <stringProp name="Argument.value">A-100</stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> </collectionProp> ``` ## Why this matters when two people edit one plan Three consequences fall straight out of the encoding, and they are what a team feels when two engineers touch one plan on the same day: 1. **A one-field change is a one-line diff, but an unreadable one.** `HTTPSampler.path` tells a reviewer what changed only if the reviewer already knows the key. Nothing in the line says which sampler it belongs to — that is thirty lines up, in the `testname` attribute. 2. **A list edit is positional.** Adding an argument in the middle of a `collectionProp` rewrites nothing, but two people adding one at the same index produce a conflict that a text merge will happily resolve into a plausible, wrong order. 3. **A nested element looks like a top-level element.** An `elementProp` carries `guiclass`, `testclass`, `testname` and `enabled` just like a tree element does, so a hunk of diff can easily be read as a new sampler when it is really a controller embedded in a Thread Group. ## A quick reading discipline When you are handed a `.jmx` hunk with no context, read it in this order: find the nearest enclosing element tag and its `testname`, then the property `name`, then the tag type. That order tells you *which element*, *which field*, and *what kind of value* — and it is the only reliable way to review a plan change as text at all.

  • In a JMeter .jmx, why does ThreadGroup.num_threads appear as an intProp in one plan and a stringProp in another?
    Because the tag follows the value, not the field. JMeter 6 declares num_threads as an integer property and the GUI stores an IntegerProperty whenever the text parses as a number, falling back to a StringProperty when it does not — which is how the field still carries an expression such as ${__P(threads,10)}. Older plans stored it as text either way, and a loaded plan keeps that tag until the GUI rewrites the element.
  • In a JMeter .jmx, how is an elementProp different from an element that sits in the tree?
    An elementProp is a property of its parent element, written inline with an elementType attribute, and it has no paired hashTree. A tree element is a key in a hashTree and always has a subtree node after it.

saying these in an interview costs you the question

  • Thinks the tag name is the field name
  • Assumes every numeric field uses intProp
  • Reads an elementProp as a separate tree element
  • Believes collectionProp entries are matched by name
  • Says property tags may be freely renamed by hand