Testing

It splits the test body into three blocks: Arrange builds the fixture and inputs, Act invokes the one behaviour under test, and Assert checks the outcome. Keeping a single Act per test means a failure points at exactly one behaviour, and the fixed shape lets any reader scan an unfamiliar test in seconds. It is a convention, not something JUnit enforces.

@Test marks one no-argument test method. @ParameterizedTest runs the same method once per input taken from a declared source such as @ValueSource or @CsvSource. @RepeatedTest(n) runs the method n times. JUnit 5 also builds a fresh test-class instance for every test, so tests cannot leak state into one another.

Red: write a failing test for behaviour that does not exist yet, and watch it fail. Green: write the simplest code that makes it pass, however crude. Refactor: clean up code and test while the suite stays green, so the tests act as a safety net. Then repeat in small increments — the test is written first, and it drives the design.

The tests share mutable state through the static list and depend on execution order, which JUnit 5 does not guarantee. When createsOrder runs first, ORDERS.get(0) is today's order, which is not expired — so the assertion fails. Run alone or in the other order, it passes. Fix by making the fixture per-test (a non-static field, reset in @BeforeEach) and asserting on the order the test itself created, not on index 0.

A mock is a generated fake object: every method returns a default (null, 0, false) until you say otherwise, and its calls can be checked with verify. Stubbing is what you do to a double — when(x.f()).thenReturn(v) pins a canned answer on one call. A spy wraps a real instance: unstubbed methods run the real implementation, only the stubbed ones are replaced. So mock and spy are the objects; stubbing is the behaviour you attach.

Introduce consumer-driven contract tests. Each consumer writes, against a local stub of the producer, the requests it makes and the response fields it actually reads — that expectation is the contract, published to a broker. The producer's build then replays every published contract against its real API and fails when a field a consumer reads has moved or vanished, so the rename would have failed the orders build before the deploy. No shared environment is needed.

A tool such as PIT makes small changes to the compiled production code — flips > to >=, replaces a return value, deletes a call — and re-runs the suite against each mutant. A mutant that makes some test fail is killed; one the green suite never notices survives, and the score is killed/total. It therefore measures whether your assertions detect wrong behaviour, while line coverage only proves the line ran — a test with no assertions still covers 100%.

Split by what a test actually needs. Pure logic — discounts, rounding, coupon rules — has no reason to boot Spring: instantiate the class, mock its collaborators, run in milliseconds. That is the bulk of the 400. Keep an integration test only where the thing under test is the wiring: JPA mappings, transaction rollback, the controller's JSON contract — a mocked repository can never fail a mapping. The payment provider stays out of both, replaced at its boundary.