You place JUnit Jupiter's @Timeout on a test class rather than on one method. Which methods does it then govern, and how is the effective limit resolved if a method or an inner class also declares one?

## What class-level means `@Timeout` is declared with a target that includes types, so you can write it once above the class instead of on twenty methods. Jupiter then treats every method it invokes in that class as if it carried the annotation: - testable methods: `@Test`, `@ParameterizedTest`, `@RepeatedTest`, `@TestFactory`, `@TestTemplate`; - lifecycle callbacks: `@BeforeAll`, `@AfterAll` (once per class) and `@BeforeEach`, `@AfterEach` (once per test). The practical value is in the lifecycle coverage. Suites that hang usually hang in setup — a database container that never becomes ready, a WireMock server bound to a busy port, a pool waiting for a connection. A class-level annotation catches those without you remembering to annotate each callback. ## Per method, not per class This is the misconception interviewers probe. The annotation never expresses a budget for the whole class or the whole run; it is copied onto each method. With `@Timeout(5)` on a class holding fifty tests, the class may legitimately take four minutes; only an individual method exceeding five seconds fails. Likewise a `@RepeatedTest(100)` under a class-level budget gives each of the hundred repetitions its own budget, not the set of them. ## Nested classes and inheritance Jupiter's `@Nested` inner classes inherit the enclosing class's applicable timeout, so an outer declaration protects the whole hierarchy. Inheritance from a superclass or an interface follows Jupiter's normal rules for inherited annotations: a test class extending an abstract base whose class-level `@Timeout` is present is governed by it, and inherited lifecycle methods are governed by the annotation applicable where they are resolved. ## The precedence ladder From weakest to strongest: 1. Suite-wide defaults expressed as JUnit Platform configuration parameters, including the category-specific ones (a default just for `@BeforeEach`, for instance). 2. `@Timeout` on an enclosing test class. 3. `@Timeout` on the immediate (possibly `@Nested`) class. 4. `@Timeout` on the method itself. The nearest declaration wins outright. It does not intersect with outer declarations, and it is not required to be stricter: a method may legally raise its budget above the class's, which is the intended escape hatch for the one slow test in an otherwise fast class. There is no way to express "whichever is smaller"; if you want that, you have to write the number you mean. ## Thread mode interacts the same way `threadMode` travels with the annotation, so a class-level `@Timeout(value = 5, unit = SECONDS, threadMode = SEPARATE_THREAD)` puts every method in the class — including lifecycle callbacks — on a separate thread. That is rarely what you want in a class using thread-bound state such as a Spring test transaction, so class-level declarations are usually left at the inferred (same-thread) mode, with the aggressive mode applied narrowly at method level. ## Practical patterns A common layering in real suites: no annotation at all on the majority of classes, relying on a generous suite-wide default as a deadlock net; a class-level annotation on integration-test classes whose setup talks to containers or networks; and method-level overrides in two directions — tighter on a method that must not hang, looser on the single known-slow test. Where a whole category of tests shares a budget, some teams put `@Timeout` on a custom annotation applied to those classes so the number lives in one place. The review guidance is the same as for method-level use: the class budget should sit far enough above the slowest legitimate method that ordinary CI noise cannot reach it. A class-level number chosen from a laptop's timings is a flakiness generator multiplied across every method in the class, because a single overloaded agent can now trip many tests at once and make the failure look like a systemic outage rather than a slow machine.