Ch. 22 · Software Testing

Mutation Testing and Assertion Strength

Mutation Testing and Assertion Strength. Learn the reasoning, a practical example, common mistakes and an interview exercise.

~2 min readintermediateupdated Oct 3, 2026

Mutation testing changes code in small ways to see whether tests detect incorrect behavior. Surviving mutants can reveal missing assertions or irrelevant mutations.

Before you start

You should understand inputs, expected outputs and the boundaries of the component under test. State the risk a test should detect before choosing a tool or mock. Distinguish controlled dependencies from real integrations so the result does not imply more coverage than the test actually provides.

The practical goal is to reason through this situation: Changing greater-than to greater-or-equal should be caught by a boundary test. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.

Step-by-step walkthrough

Step 1: Identify the mutation’s effect

A changed comparison may alter only one boundary.

Step 2: Check survivor relevance

Some changes do not affect the supported contract.

Step 3: Add justified assertions

Test a real observable gap rather than optimizing a score blindly.

Worked scenario

Changing greater-than to greater-or-equal should be caught by a boundary test.

A maximum-ten check changes from greater-than to greater-or-equal. The altered implementation rejects exactly ten, and a boundary case should detect it. If a mutant changes unreachable code, adding an artificial test solely to kill it may not improve meaningful confidence. Explain what user behavior differs first.

Common mistake

Killing every mutant is not a substitute for a meaningful domain test strategy.

Verify the behavior

Trace surviving mutants to supported observable requirements before changing tests.

Interview exercise

Investigate a survivor.

Answer and reasoning

Determine whether it changes observable behavior, then add a focused test only when a real coverage gap exists.

Continue learning

Compare the scenario with the Software Testing interview questions and test your understanding with the Software Testing MCQs. For terminology and implementation details, consult the reference material.

More in Software Testing

read ✓Software Testing · hard

Testing Time with an Injected Clock

Inject a clock instead of calling the system time, freeze it in tests, and remove the sleeps that make tests flaky.

~2 min readread →
read ✓Software Testing · mid

Code Coverage and Its Limits

Read line and branch coverage as a signal, not a goal, and avoid the tests that chase the number without checking behavior.

~2 min readread →
read ✓Software Testing · hard

Scoping End-to-End Tests

Reserve end-to-end tests for critical user journeys, use stable selectors, and avoid duplicating coverage the lower tests already have.

~2 min readread →
esc