Across a team's JMeter plans, at which tree level would you standardise attaching shared elements?

## Why this is a decision and not a default JMeter's scoping rules make depth semantic. An element attached under the Test Plan is in scope for every sampler in every Thread Group, including setUp and tearDown groups; the same element under a controller reaches only that branch. Nothing in the GUI shows a sampler which elements it has inherited, so the reach of a high attachment is invisible at the point where it matters. That is the whole trade: **high attachment costs legibility, low attachment costs duplication.** There is also a time axis. Scope is inherited by samplers that do not exist yet. Whatever you attach at Thread Group level today applies to whatever a colleague adds to that group next quarter, and nobody will re-read your decision when they do. ## A split that holds up 1. **Universal and inert — attach high.** Elements whose reach genuinely is the whole plan and whose effect is harmless where it is not needed. A single results listener for the run belongs here, as does a defaults element expressing values that are true for every request. 2. **State-carrying managers — exactly once per Thread Group.** The Cookie and Authorization Managers are not merged; if two are in scope, one is used and the manual does not define which. Making "one per Thread Group, directly under it" a rule removes a whole class of silent defect. 3. **Flow-specific — attach to the controller that owns the flow.** A timer, an extractor or a Header Manager that belongs to checkout goes under the checkout controller. The configuration then travels with the flow when it is copied, and its reach is obvious from the indentation. 4. **Request-specific — attach to the request.** Assertions on a particular response and headers for a particular call belong under their sampler. Yes, you will repeat yourself; the repetition is what makes the plan readable. ## What each choice costs | Level | Reach | What it buys | What it costs | | --- | --- | --- | --- | | Test Plan | every sampler, all groups | one place to change | reach invisible from any sampler | | Thread Group | one population | matches how load is shaped | new samplers silently inherit it | | Controller | one flow | configuration moves with the flow | repeated per flow | | Sampler | one request | scope obvious in review | most duplication and drift | ## Making the convention enforceable A convention nobody can check is a preference. Cheap checks that actually work on `.jmx` files: - Count `CookieManager` and `AuthManager` elements per Thread Group in the file and fail the review above one. - Count timers on each sampler's path; more than one means a summed pause that someone has to justify. - Require any Header Manager attached above Thread Group level to name, in its element name, why it is universal. - Treat a reusable fragment that carries its own session manager as a defect, since composing it into a plan that has one creates a second in scope. These are structural checks, which is what makes them reviewable — none of them requires running the plan. ## Where reasonable people differ Teams that own few, long-lived plans usually push attachment down, accepting duplication because their plans are read far more often than they are edited. Teams that generate plans, or maintain many near-identical ones, push it up, because a single edit propagating everywhere is exactly the property they want. Both are defensible. What is not defensible is mixing the two without saying so, which is how plans end up with a Header Manager at plan level, another under a Thread Group, and a third under a controller — a merge nobody designed. The judgment to demonstrate is that you have picked a rule, written down why, and made the failure modes of the rule cheap to detect rather than pretending your level is universally correct.