In an Apache JMeter test plan, what are the element families and what does each one contribute?
answer
- The Add menu is the taxonomy
- Eleven categories, not a loose list
- Minimum plan: plan, threads, sampler
- Two families the Test Plan node refuses
basics
~20 sJMeter's Add menu groups elements into families: Threads (Users), Sampler, Logic Controller, Config Element, Timer, Pre Processors, Post Processors, Assertions, Listener, Test Fragment and Non-Test Elements. The family tells you what an element does around a sampler.
solid answer
~50 sA JMeter plan is a tree whose every node belongs to one family, and the family is the element's job description. A **Thread Group** is where execution begins; the manual states that all controllers and samplers must sit under one. **Samplers** send a request and produce a sample result. **Logic Controllers** send nothing themselves and decide which of their children run, and how often. **Config Elements** do not send requests but add to or modify the ones samplers send. **Timers** pause before each sampler in their scope. **Assertions** judge a response and can turn a technically successful sample into a failed one. **Listeners** consume results and may hang anywhere, collecting only from elements at or below their level. **Pre-** and **Post-Processors** act around a sampler. **Test Fragments** and **Non-Test Elements** hold no load of their own.
code
text · 19 linesTest Plan <- plan-level settings + User Defined Variables
HTTP(S) Test Script Recorder <- Non-Test Elements (authoring tool, no load)
setUp Thread Group <- Threads (Users), runs first, to completion
JSR223 Sampler "seed accounts" <- Sampler
Thread Group "checkout" <- Threads (Users), the measured work
HTTP Request Defaults <- Config Element (modifies requests)
HTTP Cookie Manager <- Config Element
Constant Timer <- Timer (pauses before each sampler in scope)
Once Only Controller <- Logic Controller
HTTP Request "login" <- Sampler
Transaction Controller "checkout" <- Logic Controller (also emits a sample)
HTTP Request "cart" <- Sampler
Response Assertion <- Assertion (can fail a 200)
JSON Extractor <- Post Processor
HTTP Request "pay" <- Sampler
tearDown Thread Group <- Threads (Users), runs last
JDBC Request "purge test rows" <- Sampler
Test Fragment "shared login" <- inert unless a Module/Include Controller calls it
Simple Data Writer -> results.jtl <- Listener (plan level: sees everything below)go deeper
Be able to name the families out loud and give one example element for each. Knowing that a plan needs at least a Test Plan, a Thread Group and a Sampler already puts you ahead of most screening candidates.
Explain what membership implies: a Config Element modifies a request but never sends one, a Logic Controller shapes which samplers run, an Assertion only downgrades a result unless its Ignore status box is ticked. Say why samplers cannot live directly under the Test Plan.
Use the taxonomy as a review tool. Open an unfamiliar plan, label every node by family, and from that alone say which elements generate traffic, which only shape it, and what will end up in the result file.
Own the convention. Decide which families a house plan skeleton mandates, which are banned from committed plans, and how reviewers check that, so plans stay readable across teams rather than each one being a personal arrangement.
## Why the families are the first thing an interviewer probes A JMeter test plan is a tree, and every node in it belongs to exactly one family. Those families are not a documentation convenience: they are the categories the GUI's **Add** menu is assembled from, and membership decides what an element is allowed to do to a request. Naming an element's family is therefore the shortest possible way to say what it contributes, which is why "open this plan and walk me through it" is such a common opening. The manual sets a very small floor: *a minimal test consists of the Test Plan, a Thread Group and one or more Samplers*. Everything else is additive. ## The eleven families JMeter 6.0.0 registers `MenuFactory` registers eleven named categories (plus a separator). These are the labels you actually see: | Add-menu family | What it contributes | | --- | --- | | Threads (Users) | Thread Group, setUp Thread Group, tearDown Thread Group, Open Model Thread Group — the elements that create threads and start execution | | Sampler | Issues a request and produces a sample result: HTTP Request, JDBC Request, Debug Sampler, Flow Control Action | | Logic Controller | Decides which children run and how often: Loop, If, While, Interleave, Transaction, Module, Include, Critical Section | | Config Element | Does not send a request; adds to or modifies the requests samplers send | | Timer | Pauses before each sampler in its scope | | Pre Processors | Acts on a sampler's request before it is issued | | Post Processors | Acts on the response a sampler produced | | Assertions | Judges a response and can mark an otherwise successful sample failed | | Listener | Consumes sample results — displays them, writes them to a result file, or both | | Test Fragment | A container that lives beside a Thread Group and is not executed unless something references it | | Non-Test Elements | Authoring and diagnostic tools such as the HTTP(S) Test Script Recorder, HTTP Mirror Server and Property Display | ## What each family actually contributes Some distinctions are worth stating out loud rather than assumed: - **Thread Group is the entry point.** The manual is explicit that all controllers and samplers must be under a thread group. That is why the Test Plan node's own Add menu offers Threads, Config Element, Listener, Timer, Pre/Post Processors, Assertions, Test Fragment and Non-Test Elements — but neither Sampler nor Logic Controller. - **Samplers and Logic Controllers are both "controllers" in JMeter's vocabulary.** The manual says JMeter has two kinds of controller: samplers, which send requests, and logic controllers, which shape the order in which samplers are processed. - **A Config Element does not send anything.** It "works closely with a Sampler" and can add to or modify a request. The one documented exception is the HTTP(S) Test Script Recorder, which is also a Non-Test Element. - **A Timer is a delay, not a rate.** It causes JMeter to wait a certain time *before* each sampler in its scope. - **An Assertion normally only makes things worse.** In the ordinary path it can mark a technically successful sample as failed but never the reverse — `JMeterThread.processAssertion` ANDs the assertion outcome into the existing status. The documented way back is the Response Assertion's *Ignore status* box (`Assertion.assume_success`, default off): `ResponseAssertion` calls `response.setSuccessful(true)` before evaluating, to allow testing of failure codes, which is how you assert on an expected 404. It also clears any earlier assertion failure, so it must only be set on the first assertion. - **A Listener is passive.** It reads results. The manual notes that all listeners save the same data — they differ only in how they present it — and that a listener collects only from elements at or below its own level. - **A Test Fragment is inert on its own.** It sits at the same level as a Thread Group and never runs unless a Module Controller or an Include Controller references it. ## Reading a plan family by family Given an unfamiliar `.jmx`, the productive first pass is not to read fields but to label nodes: 1. Which Threads (Users) elements exist, and are any of them setUp or tearDown groups? That fixes the phases of the run. 2. Which samplers exist? Those are the only nodes that will produce traffic. 3. Which logic controllers wrap them? Those change how often each sampler fires. 4. What hierarchical elements — config, timers, assertions, listeners, processors — are attached, and at which node? After that pass you can describe the plan without having opened a single panel, and you can already say what will and will not appear in the result file. ## The trap Candidates who have only clicked around the GUI describe a plan element by element ("there's an HTTP Request, then a CSV thing, then a graph"). Candidates who know the taxonomy describe it family by family, and that difference is exactly what the question is measuring.
- Which two families does the Test Plan node's Add menu deliberately not offer?Sampler and Logic Controller. The manual states that all controllers and samplers must sit under a thread group, because a thread is what executes them, so the Test Plan node offers Threads, Config Element, Listener, Timer, Pre and Post Processors, Assertions, Test Fragment and Non-Test Elements only.
- The plan has a Test Fragment full of samplers, yet nothing in it ever runs. Is that a bug?No. A Test Fragment sits at the same level as a Thread Group and is not executed unless a Module Controller or an Include Controller references it. It exists purely for re-use, and JMeter has disabled it by default in the tree since 2.13 so it cannot run itself.
- Where do Non-Test Elements fit, and should they be in a plan you commit?Non-Test Elements are authoring and diagnostic tools — the HTTP(S) Test Script Recorder, HTTP Mirror Server and Property Display. They carry no load and produce no samples. Keeping a recorder in a committed plan is noise at best, so most teams strip them once the plan is captured.
saying these in an interview costs you the question
- Calling everything a component and never naming its family
- Believing a Sampler can be added directly under the Test Plan node
- Claiming Config Elements send requests of their own
- Treating Listeners as elements that change what the test does
- Assuming a Test Fragment runs because it sits on the plan tree