In a JMeter test plan, what does a Test Fragment element do when the plan runs?
answer
- Think container, not runnable branch
- Sits under the Test Plan itself
- Two controllers can reach it
- The GUI creates it already disabled
basics
~20 sA Test Fragment holds test elements but never runs on its own. It sits under the Test Plan beside the Thread Groups, and JMeter executes its contents only when a Module Controller or an Include Controller references it.
solid answer
~40 sA **Test Fragment** is a controller that lives directly under the Test Plan node, at the same level as a Thread Group, and it is deliberately not executed. JMeter runs what is inside it only when a **Module Controller** points at it through its *Module To Run* field, or an **Include Controller** loads the `.jmx` file that contains it. The GUI even creates the element already disabled — `TestFragmentControllerGui.createTestElement()` calls `setEnabled(false)`, which the manual notes has been the default since JMeter 2.13 — so you cannot start it by accident. Being disabled does not block the reference: `ModuleController.getReplacementSubTree()` clones the target node and enables the clone. The element carries only a Name field; all the behaviour is in whatever you nest under it.
go deeper
Recall the one-liner: a Test Fragment is a parking place for elements, sitting at Thread Group level under the Test Plan, and it runs only when a Module Controller or Include Controller reaches it.
Explain the mechanics that actually enforce it: the GUI creates the element already disabled, JMeter deletes disabled elements while it converts the test tree at start-up, and paste or drag-and-drop refuse any parent that is not a Test Plan. The Add menu itself is looser — it offers Fragments on a Thread Group too.
Show that you know a disabled fragment still runs when referenced, because the Module Controller clones the target node and enables the clone, and that the substitution happens once before threads start.
Own the consequence for a team: a fragment is a container with no parameters and no schedule, so shared behaviour has to be shaped around the variables the calling plan already sets.
## What the element actually is In Apache JMeter 6.0.0 the Test Fragment is `org.apache.jmeter.control.TestFragmentController`, and its source is four lines long: it extends `GenericController` and adds nothing. Everything interesting about it is *where it is allowed to sit* and *what refuses to run it*. The manual puts it plainly — the Test Fragment "exists on the Test Plan tree at the same level as the Thread Group element", it "is not executed unless it is referenced", and it is "purely for code re-use within Test Plans". Its GUI exposes exactly one property: - **Name** — the descriptive label shown in the tree. It is not cosmetic: a Module Controller finds its target by walking element **names**, so this field is the address other elements use. ## Why it never runs on its own JMeter's unit of execution is the Thread Group. A Test Fragment is not one, so nothing ever allocates threads to it, and two further things shape where it sits and whether it runs: 1. **Placement.** Two GUIs offer the Fragments category — `TestPlanGui.createPopupMenu()` and `AbstractThreadGroupGui.createAddMenu()`, the base of every Thread Group GUI — so a Thread Group's `Add` menu will happily create one, and `AddToTree` does not second-guess the parent. No other `Add` menu offers it: a Logic Controller's comes from `MenuFactory.getDefaultControllerMenu()` and a Sampler's from `getDefaultSamplerMenu()`, neither of which adds the category, and `TestFragmentControllerGui.createPopupMenu()` omits it too — so you cannot nest one fragment inside another from the menu. What does pin a fragment to Test Plan level is `MenuFactory.canAddTo()`, which refuses any parent that is not a `TestPlan` — but it guards paste, drag-and-drop, the `Move` shortcuts and merge, never `Add`. Beside the Thread Groups, where the manual puts it, is as much convention as enforcement. 2. **Default state.** `TestFragmentControllerGui.createTestElement()` calls `setEnabled(false)` before returning the element. A newly added Test Fragment arrives greyed out, and the component reference records that this became the default in JMeter 2.13. Disabled matters because when JMeter builds the runnable tree, `JMeter.pConvertSubTree()` walks it and **removes every disabled element** before a single thread starts. A fragment left at its default therefore vanishes from the tree that actually runs. ## How a reference wakes it up Two controllers can reach a fragment, and they differ in where the fragment has to live: | | Module Controller | Include Controller | |---|---|---| | Where the target lives | anywhere in the **same** loaded plan tree | inside a **separate** `.jmx` file | | How it is addressed | the *Module To Run* picker, stored as a path of element names | the *Filename* field | | Visible in the GUI | yes — the target is a node you can open and edit | no — the contents are not displayed | Both resolve at the same moment: the substitution happens while JMeter converts the test tree, before any thread starts, not on each pass through the branch at run time. ## Disabled, and still referenced The interesting consequence is that a disabled fragment still executes when something points at it. `ModuleController.getReplacementSubTree()` checks the target node, and if it is not enabled it clones the node, sets the clone enabled, and returns that clone with its children attached. The original stays disabled in the tree and is pruned as usual. So the two rules — *disabled elements are deleted* and *fragments are disabled by default* — do not fight each other. ## A login flow shared by three plans Say a login flow is worth writing once and running from three separate plans. The fragment is the container you put it in: - open the plan, add a **Test Fragment** under the Test Plan node, and name it something unmistakable such as `Login Fragment`; - nest the login samplers, the extractor that captures the session token, and whatever controllers they need underneath it; - leave it disabled — that is the point of it; - have each plan reach it, with a Module Controller if the fragment lives in that same plan file, or with an Include Controller if all three plans read one shared file. JMeter also ships a shortcut for producing that file: selecting a set of nodes and using the **Save as Test Fragment** action creates a new Test Fragment node, deep-clones the selection under it, and writes the result to a `.jmx` of your choosing. ## What the element deliberately does not give you - **No schedule.** It has no thread count, ramp-up, loop count or duration field; those belong to whatever Thread Group ends up running the referencing branch. - **No parameters.** Neither controller passes arguments to a fragment. The fragment simply reads whatever variables the calling plan has set — feeding those is a different subject entirely. - **No renaming of results.** The samplers spliced in are the fragment's own elements, so all three plans report the login steps under the fragment's sampler names.
- How do you turn an existing group of samplers in a JMeter plan into a Test Fragment?Select the nodes and use the Save as Test Fragment action. JMeter creates a fresh Test Fragment element, deep-clones the selected subtree under it, and saves that to a .jmx file you name. The result is exactly the shape an Include Controller expects, since it looks for a Test Fragment in the file it loads.
- Can a JMeter Test Fragment sit inside a Thread Group?Yes, through the Add menu — a Thread Group's Add menu carries the Fragments category too (AbstractThreadGroupGui.createAddMenu()), and nothing in AddToTree refuses the parent. What JMeter does block is pasting or dragging one there: MenuFactory.canAddTo() forces a Test Fragment to be accepted only under a Test Plan. The manual's placement — beside the Thread Groups, under the Test Plan — is the convention that makes it reusable and keeps it out of a running branch; nesting it inside a Thread Group and enabling it just makes it an ordinary controller that runs.
saying these in an interview costs you the question
- Says a Test Fragment runs like a Thread Group
- Thinks the fragment must be enabled before it can be referenced
- Puts the Test Fragment inside a Thread Group and expects it to run
- Believes a Test Fragment carries thread count or ramp settings
- Assumes a disabled fragment cannot be executed at all