A JMeter Include Controller loads login.jmx but none of its samplers run. Why?

## What the controller keeps The Include Controller is a filter, not a paste. `IncludeController.loadIncludedElements()` parses the named `.jmx` with `SaveService.loadTree()` and then puts the result through two passes: 1. **`getProperBranch(tree)`** — iterate the top level; if a `TestPlan` is found, recurse into it; if a `TestFragmentController` is found, return **that node's subtree** and stop. If neither is found anywhere it reaches, log `No Test Fragment was found in included Test Plan, returning empty HashTree` and return an empty tree. 2. **`removeDisabledItems(tree)`** — recursively delete anything not enabled from what survived. So three separate things can leave you with an include that runs nothing: - the file has no Test Fragment at all; - the file has one, but the elements you care about are outside it; - the elements are inside it but left disabled. ## The symptom is quiet None of these is a run-stopping error. The warning goes to `jmeter.log` and the plan carries on: ``` 2026-01-14 09:31:07,442 WARN o.a.j.c.IncludeController: No Test Fragment was found in included Test Plan, returning empty HashTree ``` The same is true one step earlier, if the file cannot be opened at all: `loadIncludedElements()` catches the exception, logs, reports it, and returns nothing, and `JMeter.pConvertSubTree()` simply skips the replacement when the returned tree is null. The Include Controller then sits in the plan as an empty controller. That is worth contrasting deliberately with the other reuse mechanism. A Module Controller whose target cannot be resolved throws `JMeterStopTestException` and takes the whole run down. **The Include Controller degrades; the Module Controller stops.** When you inherit a plan, knowing which of the two you are looking at tells you whether silence is safe. ## The shape the file has to have The component reference gives the recipe: create a Test Fragment *underneath the Test Plan*, add samplers and controllers below it, save the plan, and that file is ready to include. For the login flow shared by three plans, the file looks like this: ``` login.jmx |- Test Plan |- Login Fragment <- Test Fragment: the only branch that is included | |- POST /login | `- Regular Expression Extractor: token `- Debug Thread Group <- ignored during the include `- Run Login <- Module Controller pointing at Login Fragment ``` That Thread Group is not a mistake. The manual explicitly suggests adding one "for debugging purposes", with a Module Controller referencing the Test Fragment, so the fragment can be exercised on its own; the include process throws it away. JMeter also gives you a way to produce this shape without hand-building it. The **Save as Test Fragment** action takes the nodes you have selected, creates a Test Fragment element, deep-clones the selection under it, and writes that to a file — which is exactly what the include expects to find. ## Traps around this - **Only the first fragment counts.** `getProperBranch()` returns as soon as it meets a `TestFragmentController`. A second Test Fragment in the same file is silently ignored, so one file means one includable fragment. - **Disabled elements inside the fragment vanish.** Somebody disabling one sampler "just for a local run" and committing it removes that step from all three plans. - **Plan-level state does not travel well.** The manual warns that a Cookie Manager or User Defined Variables belong in the top-level plan doing the including, not in the included file, or they "are not guaranteed to work". - **The shipped tutorial page is stale.** JMeter 6.0.0 still ships an *Include Controller Tutorial* describing a WorkBench and a Simple Controller as the file's root element. The WorkBench was dropped from the JMeter UI in 4.0, and a Simple Controller at the root is precisely the case that produces the empty-tree warning. The component reference and the code are the current contract. ## How to confirm it in a minute 1. Open `jmeter.log` and grep for `IncludeController`. The controller logs the absolute path it tried, plus either the no-fragment warning or a can't-load error. 2. Open the included `.jmx` in the GUI and check that a Test Fragment exists directly under its Test Plan and that everything you expect is nested inside it. 3. Check the enabled state of every element under the fragment. 4. Count the samplers in your results by label: an include that contributed nothing shows up as labels that never appear, not as failures.