JUnit Jupiter's Assumptions class offers both assumeTrue(condition) and assumingThat(condition, lambda). What is the behavioural difference between them, and when would you reach for the lambda form?

## Two different granularities Both methods live on `org.junit.jupiter.api.Assumptions`, but they answer different questions. `assumeTrue(boolean)` answers: *should this test run at all?* A false condition throws `org.opentest4j.TestAbortedException`, control leaves the method at once, and the platform records the aborted status, which build reports render as skipped. `assumingThat(boolean, Executable)` answers: *should this part of the test run?* It is a conditional block with a testing-flavoured name. If the condition is true it invokes the lambda; if false it returns immediately. It never throws an aborting exception, so the test continues and its final status is decided by whatever else it does. There are overloads taking a `BooleanSupplier` for the condition, so the check itself can be deferred. `Executable` is Jupiter's functional interface for a void, throwing block, the same type used by exception assertions — so the lambda can throw checked exceptions without wrapping. ## Why the scoped form exists Some tests are almost portable. A file-handling test may verify creation, reading and deletion everywhere, while permission bits are only meaningful on POSIX filesystems. Splitting that into two test methods duplicates the setup; aborting the whole test on Windows loses the portable coverage. `assumingThat(isPosix(), () -> assertEquals("rw-r--r--", permissionsOf(file)))` keeps the shared checks running and gates only the platform-specific assertion. The same pattern appears with optional capabilities: assert the response body everywhere, but only assert the compression header when the server under test advertises gzip. ## The visibility trade This convenience has a real cost. An aborted test is *reported*: it appears as skipped, usually with a message, and someone scanning results can see coverage was not delivered. A skipped `assumingThat` block is invisible. The test is green, the report says nothing, and a condition that silently became false — a renamed environment variable, a capability probe that now always returns false — quietly removes assertions from the suite forever. So the guidance is proportional to how much of the test's value sits in the block. If the conditional part is a small addendum to substantial unconditional verification, `assumingThat` is fine. If it is the point of the test, use `assumeTrue` at the top so the skip is at least visible, or split into two methods and gate one of them. A useful middle path is to log or record the skip inside the false branch, or to write the condition so it is asserted somewhere else once per suite — for example, a dedicated test that fails if the expected capability is missing in the CI environment, so silent degradation surfaces in exactly one place. ## Common mistakes The first is expecting `assumingThat` to abort. Candidates often say a false condition skips the test; it does not, and the method continues into code that may then dereference the very thing the condition was guarding — producing a confusing NullPointerException rather than a skip. The second is putting the whole test body inside the lambda. That is a verbose, less visible way of writing `assumeTrue`, with the added downside that the test now reports as passed when nothing was checked. If the entire body is conditional, the condition belongs at the top as an abort or, better, as a declarative execution condition on the method. The third is side-effectful conditions. Because `assumingThat` evaluates its condition every time it is reached, an expensive probe placed inside a loop can dominate the test's runtime; the `BooleanSupplier` overload does not help there, since the supplier is still invoked. Hoist expensive probes into a field or a `@BeforeAll`-computed value. ## Quick decision rule - The test is meaningless without the precondition → `assumeTrue` (visible skip). - The test is still meaningful, one section is not → `assumingThat`. - The precondition is statically knowable and cheap → prefer a declarative condition over either.