Mutation Testing with Mutant

When to Activate

The user asks to run mutation testing.
The user has alive mutations to fix.
The user asks to verify mutation coverage on a subject.

When Not to Use

The task does not involve mutation testing.

Inputs

Alive mutation output to act on (paste the evil: block).
Optional: subject expression to scope the run.

Outputs (Fixed Order)

Mutation results (alive count, coverage percentage).
Clear action for each alive mutation: add test or simplify code.

Reading Mutation Output

An alive mutation looks like:

evil:YourClass#method:YourClass#method:lib/your_class.rb:42:abc12
@@ -1,3 +1,3 @@
 def method
-  @value >= threshold
+  @value > threshold
 end

evil means no test killed this mutation.
The diff shows original (-) and mutated (+) code.

Reporting Format (BLUF)

Lead with the verdict — bottom line up front:

If unkillable:

Unkillable. Both forms are equivalent because [reason]. Add to ignore list.

If killable:

Killable.

Option A — add test:
(test diff)
Option B — simplify code:
(source diff)

Always present both options so the user can choose. Include evidence: if you cannot think of a test that would kill the mutation, say so — that is valuable signal toward unkillable.

Usage

1. Run Mutant

bundle exec mutant run --fail-fast

When the subject is known, scope the run to avoid testing unrelated subjects:

bundle exec mutant run --fail-fast 'Entities::CreateService#call'

If the command succeeds, coverage is 100% — done. If it fails, find the evil: line in the output — it has the subject name, file path, and line number. The diff block immediately after shows the original and mutated code.

2. Investigate

Read the source file and existing spec file for the subject. Ask: "Is the mutated code acceptable for all valid inputs?"

3. Decide and Act

Add a test when the mutated code is wrong but tests do not prove it.
Simplify the code when the mutated code is correct for all valid inputs.

Do not change both code and tests in the same commit. If both need changing, commit the test first, then simplify the code in a second commit.

4. Re-run and Verify

Re-run mutant (step 1) until 100%. If the same mutation survives after 2 attempts, evaluate whether it is unkillable.

bundle exec rspec  # full suite must pass

5. Commit

Follow the project's conventional commits format. The commit body must explain which mutation survived, why the test kills it or why the simplification is correct.

Fixing Alive Mutations

When to Add a Test

Add a test when the mutated code is wrong but the existing tests do not prove it. The test must pass with the original code and fail with the mutated code. Common reasons a test is missing:

Only one value of a boolean/flag is tested — add the other.
A collection has one element, so next and break behave the same — add a test with multiple elements.
Two objects return the same value in test data, hiding which one the code actually uses — add test data where they differ.
A method has a default parameter, and all tests pass the argument explicitly — add a test that omits the argument.

When to Simplify Code

Simplify when the mutated code is correct for all valid inputs. Apply the mutation's change directly to the source code — do not restructure or rewrite, just accept the mutated form.

Mutant encodes the principle of least power: use the most constrained primitive that satisfies the requirement. When Ruby offers multiple methods that overlap in behavior but differ in power, mutant replaces the more powerful one with the less powerful one. If tests still pass, you did not need the extra power — accept the simpler form.

Before accepting a simplification, verify the mutation preserves behavior across the method's full input domain and all call sites.

Simplification Trap: Syntax Rewriting

Do not rewrite code to eliminate a mutation axis without first ensuring the expression has test coverage. Changing syntax may make the mutation disappear without proving the code is correct. The correct sequence:

Add test coverage for the expression.
Apply the simplification mutant suggests.
Verify 100% mutation coverage on the subject.

When a Mutation Is Equivalent

When the original and mutated code produce the same result for all inputs, the mutation is equivalent. Equivalent does NOT mean unkillable. Ask: does the mutated form use a more constrained primitive? If yes, it IS the simplification — apply it to the source.

Examples: method → public_method (restricts to public API), kind_of? → instance_of? (restricts to exact class).

A mutation is only unkillable when you cannot add a test AND you cannot apply the mutation to the source.

When a Mutation Is Unkillable

Add the subject to the ignore list in config/mutant.yml with an inline comment explaining why it is unkillable.
Do not commit code or test changes for this subject.
Report: which mutation survived, why it is equivalent, and what you tried before concluding it is unkillable.

Every ignored subject must have a comment. No uncommented entries.

Prepare a Legacy Project (First-Time Setup)

When adding mutant to a project with no ignore list, run mutant once to find all alive subjects, then seed the ignore list so burn-down can start from a passing baseline:

bundle exec mutant run 2>&1 \
  | sed -n 's/^evil:\([A-Za-z][A-Za-z0-9_:]*[#.][^:]*\):.*/\1/p' \
  | LC_ALL=C sort -u \
  || true

Add each subject to the ignore list in config/mutant.yml with # legacy baseline. Then remove one subject at a time and work through its alive mutations. Commit each fix with the ignore list removal included.

Checklist

Each alive mutation has a clear action: add test or simplify code.
New tests fail against the mutated code, not just pass against the original.
Full RSpec suite passes after each change (bundle exec rspec).
Each commit touches one subject only.
Unkillable mutations are in the ignore list with a comment.
Report: which mutation survived, which option was chosen, and why.

mutation-testing