Every JUnit 5 extension callback receives an ExtensionContext object. What does it give you, and what does its parent/root chain represent at run time?

## The execution tree The JUnit Platform models a test run as a tree of descriptors. Jupiter mirrors that tree with `ExtensionContext` objects: ``` engine (root) └── class OrderServiceTest ├── method createsOrder() ├── method rejectsEmptyCart() └── @Nested class WhenCartIsEmpty └── method fails() ``` When a callback fires, the context you receive is the node currently being processed. `BeforeAllCallback.beforeAll` receives the **class** context; `BeforeEachCallback.beforeEach` receives the **method** context whose parent is the class context. A `@Nested` class's context has the outer class context as its parent. `getRoot()` returns the engine-level context, which exists for the entire run. This is why the same extension instance can serve many contexts: an extension is generally a stateless strategy object, and everything *stateful* is keyed by the context it belongs to. ## What you can ask a context **Identity and metadata.** `getTestClass()` and `getTestMethod()` return `Optional`s because not every node has both (a class context has no method). The `getRequired*` variants throw instead of returning empty, which is convenient inside a callback where you know the node type. `getUniqueId()` is the platform's stable identifier for the node — useful as a store key. `getDisplayName()` and `getTags()` let an extension react to naming or `@Tag` metadata, e.g. skipping heavyweight setup for tests tagged `fast`. **Configuration.** `getConfigurationParameter(String)` (and the typed overload with a converter) reads platform configuration parameters — the same values that come from `junit-platform.properties`, system properties, or the launcher request. Since `@ExtendWith`-registered extensions are constructed with a no-arg constructor, this is the idiomatic way to make such an extension configurable. **Reporting.** `publishReportEntry(key, value)` records a timestamped entry that surfaces in the test report — the sanctioned way for an extension to emit information without printing to stdout. **Outcome.** In `AfterTestExecutionCallback`/`AfterEachCallback`, `getExecutionException()` returns the throwable the test failed with, if any. Extensions that dump diagnostics on failure (screenshots, container logs, thread dumps) branch on this. **State.** `getStore(Namespace)` returns a `Store` scoped to *this* context. Because contexts are hierarchical, the store is too: reads consult ancestors, writes are local. That single design decision is what gives you per-method, per-class and per-run state with one API. ## Lifetime rules that matter An `ExtensionContext` is only valid during the callbacks for its node. Do not stash a method context in a field and use it later — it may be closed, and its store cleaned up. If you need state to outlive a node, put it in a **higher** context's store, not in a field on the extension, and definitely not in a static. The practical translation: to make something last for the whole class, ask for it in `beforeAll` (class context) or call `context.getParent()` from a method callback; to make it last for the whole run, use `context.getRoot().getStore(...)`. ## Why not just use fields? Extension instances are not guaranteed to map one-to-one to contexts — one declaratively registered extension serves a class and all its methods, and under parallel execution several methods run concurrently against it. Fields would be shared mutable state with a race condition. The context (and its store) makes the scope explicit and is thread-safe by design.