Mutation Testing

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)

1. Mutation results (alive count, coverage percentage).
2. 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.