Testing

Acceptance testing judges a change against the stated acceptance criteria of the requirement it implements, not against the shape of the code. It passes when every criterion is demonstrably met, and those criteria are agreed before the work starts.

A consumer-driven contract records the requests one consumer sends and the response parts it actually reads, then asserts the provider can still produce them. It checks the shape of the boundary, not whether the provider's answers are correct.

An end-to-end test drives the fully assembled, deployed system through a real entry point, with nothing inside the system replaced by a stand-in, and checks the observable outcome of a complete journey rather than any internal call or state.

Integration tests catch defects that live in the boundary itself: wiring and configuration, serialization, schema and type mapping, and real query behaviour. A programmed double returns what you assumed, so it can never contradict that assumption.

The test pyramid is a shape guideline for an automated suite: many fast, narrow unit tests at the base, fewer tests across a real boundary above them, and a thin end-to-end layer on top. Width means test count.

Replace collaborators that cross a process boundary, are slow, or are nondeterministic, such as remote services, queues and clocks. Leave value objects, pure calculations and cheap in-process helpers real, because replacing those deletes the behaviour the test exists to check.

A dummy is passed but never used. A fake has a working lightweight implementation. A stub returns canned answers. A spy records the calls it received. A mock holds expectations and fails the test itself when they are not met.

Interaction verification asserts how the unit called its collaborators - which method, how often, with which arguments. State verification only checks what came back or the state afterwards. Use interaction checks when the effect leaves nothing to return.

Stubbing replaces a collaborator's method with a canned answer the test chose in advance. The unit under test then runs down a known path, without depending on the real dependency's data, speed or availability.

A stub supplies canned answers so the code under test can run; it can never fail a test. A mock is configured in advance with the calls it must receive and fails the test itself when the run does not match.

Arrange builds the fixture, inputs and collaborators the test needs. Act invokes the one behaviour under test and captures its result. Assert compares that outcome with the expected one. Given-When-Then names the same three phases.

A flaky test gives different verdicts on unchanged code, passing on one run and failing on the next. A consistent failure names a real problem; a flaky one teaches the team to re-run instead of investigate, destroying the suite's signal.

An independent test arranges everything it needs itself, writes to no state another test can observe, and leaves the environment as it found it. It gives the same verdict alone, in any position in the run, or beside tests on another worker.

Assertion roulette is a test carrying many unnamed assertions, so a failure reports only a line number and you must guess which check broke. Remove it by naming each assertion or splitting the test so one behaviour gets one test.

The usual families are timing assumptions, concurrency races, uncontrolled inputs such as the real clock, time zone or random values, calls to real external systems, dependence on the order cases run in, and state leaked between cases.

Test the edges, not the middle: 0 and 1 low, 60 and 61 high. Defects hide where a comparison flips from accept to reject, so each limit gets a value on it and one just past.

A decision table is a grid whose rows list the conditions of a rule set and the actions they produce. Each column is one rule: one combination of condition outcomes plus the actions it triggers. Each surviving rule becomes one test case.

Equivalence partitioning splits the input domain into classes the software is specified to handle identically, then tests one representative from each valid and each invalid class. If a class really is uniform, one value speaks for all of it.

Pairwise test design picks a small set of configurations in which every pair of values from two different parameters appears together at least once. It is tiny compared with the full cross-product because a single row covers many pairs simultaneously.

A state is a condition the system rests in between inputs. An event is an incoming trigger. A guard is a condition that must hold for that trigger to fire. A transition is the resulting move plus any action it performs.

An approval test runs the code, writes the output to a received artefact, and compares it against a previously approved artefact. Nobody types the expected value: a human reviews the output once and approves it, and the test then guards that exact output.

Line coverage counts source lines executed at least once. Branch coverage counts which outcomes of each decision were taken, the true side and the false side. A line can execute while one of its two outcomes never runs.

Yes. Coverage instrumentation records which code the tests executed, not whether anything checked the result. A suite that calls every function and asserts nothing still reports 100%, and proves only that the code runs without crashing.

Mutation testing seeds small deliberate faults into the code and reruns the tests. A fault the tests catch is a killed mutant; one no test notices survives, showing that code is executed but never actually asserted on.

Because values that change every run make the received artefact differ from the approved one even when the code has not changed. The test then fails nondeterministically, so teams re-approve reflexively and the approval stops meaning anything.