Stryker

Stryker.NET

Trigger On

• the repo uses or wants Stryker.NET
• mutation testing is needed for high-risk code

Value

• produce a concrete project delta: code, docs, config, tests, CI, or review artifact
• reduce ambiguity through explicit planning, verification, and final validation skills
• leave reusable project context so future tasks are faster and safer

Do Not Use For

• every PR path by default in a large repo
• simple coverage collection

Inputs

• the nearest AGENTS.md
• target projects and critical paths
• time budget for mutation runs

Quick Start

1. Read the nearest AGENTS.md and confirm scope and constraints. 2. Run this skill's Workflow through the Ralph Loop until outcomes are acceptable. 3. Return the Required Result Format with concrete artifacts and verification evidence.

Workflow

1. Run mutation testing on critical projects, not blindly on the whole mono-repo. 2. Keep it out of the fastest PR path unless the repo explicitly accepts the runtime cost. 3. Stabilize tests first; mutation testing amplifies flaky or slow suites.

Bootstrap When Missing

If Stryker.NET is not configured yet:

1. Detect current state:

• rg --files -g '.config/dotnet-tools.json'
• dotnet tool list --local
• dotnet tool list --global

2. Prefer local tool installation for reproducible CI:

• dotnet new tool-manifest (if missing)
• dotnet tool install stryker

3. Choose a focused target scope and mutation budget before enabling CI. 4. Add a dedicated mutation command in AGENTS.md and CI (not in the fastest PR path by default). 5. Run dotnet stryker on the target project and return status: configured or status: improved. 6. If mutation testing is explicitly out of scope, return status: not_applicable.

Deliver

• explicit mutation-test scope
• reproducible Stryker commands

Validate

• the selected scope is affordable in CI
• mutation score is interpreted with test quality, not as a vanity number

Ralph Loop

Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.

1. Plan first (mandatory):

• analyze current state
• define target outcome, constraints, and risks
• write a detailed execution plan
• list final validation skills to run at the end, with order and reason

2. Execute one planned step and produce a concrete delta. 3. Review the result and capture findings with actionable next fixes. 4. Apply fixes in small batches and rerun the relevant checks or review steps. 5. Update the plan after each iteration. 6. Repeat until outcomes are acceptable or only explicit exceptions remain. 7. If a dependency is missing, bootstrap it or return status: not_applicable with explicit reason and fallback path.

Required Result Format

• status: complete | clean | improved | configured | not_applicable | blocked
• plan: concise plan and current iteration step
• actions_taken: concrete changes made
• validation_skills: final skills run, or skipped with reasons
• verification: commands, checks, or review evidence summary
• remaining: top unresolved items or none

For setup-only requests with no execution, return status: configured and exact next commands.

Load References

• references/stryker.md
• references/commands.md
• references/patterns.md

Example Requests

• "Add Stryker for this library."
• "Use mutation testing on our critical domain layer."

Stryker CLI Commands and Configuration

CLI Commands

Basic Run

dotnet stryker

Run with Project Specification

dotnet stryker --project MyProject.csproj

Run with Test Project

dotnet stryker --project MyProject.csproj --test-project MyProject.Tests.csproj

Run with Solution

dotnet stryker --solution MySolution.sln

Run with Mutation Level

dotnet stryker --mutation-level Basic
dotnet stryker --mutation-level Standard
dotnet stryker --mutation-level Advanced
dotnet stryker --mutation-level Complete

Run with Concurrency

dotnet stryker --concurrency 4

Run with Reporters

dotnet stryker --reporter html
dotnet stryker --reporter json
dotnet stryker --reporter markdown
dotnet stryker --reporter progress
dotnet stryker --reporter cleartext
dotnet stryker --reporter dashboard

Run with Thresholds

dotnet stryker --threshold-high 80 --threshold-low 60 --threshold-break 40

Dry Run (No Mutations)

dotnet stryker --dry-run

Filter Files

dotnet stryker --mutate "**/*.cs" --mutate "!**/Migrations/**"

Filter Mutations

dotnet stryker --ignore-mutations Linq
dotnet stryker --ignore-mutations String
dotnet stryker --ignore-mutations Arithmetic

Configuration File

Stryker uses stryker-config.json in the project root.

Minimal Configuration

{
  "stryker-config": {
    "project": "MyProject.csproj"
  }
}

Standard Configuration

{
  "stryker-config": {
    "project": "MyProject.csproj",
    "test-projects": ["MyProject.Tests.csproj"],
    "mutation-level": "Standard",
    "thresholds": {
      "high": 80,
      "low": 60,
      "break": 40
    },
    "reporters": ["progress", "html"],
    "concurrency": 4
  }
}

Full Configuration

{
  "stryker-config": {
    "project": "MyProject.csproj",
    "test-projects": ["MyProject.Tests.csproj", "MyProject.IntegrationTests.csproj"],
    "solution": "MySolution.sln",
    "mutation-level": "Advanced",
    "mutate": [
      "**/*.cs",
      "!**/Migrations/**",
      "!**/Generated/**"
    ],
    "ignore-mutations": [
      "Linq"
    ],
    "thresholds": {
      "high": 80,
      "low": 60,
      "break": 40
    },
    "reporters": ["progress", "html", "json"],
    "report-file-name": "mutation-report",
    "concurrency": 4,
    "log-level": "info",
    "coverage-analysis": "perTest",
    "disable-bail": false,
    "since": {
      "enabled": true,
      "target": "main"
    }
  }
}

Key Options Reference

Mutation Levels

Reporters

Coverage Analysis Modes

Incremental Mutation Testing

Enable incremental mutation testing to only test changed code:

{
  "stryker-config": {
    "since": {
      "enabled": true,
      "target": "main"
    }
  }
}

CLI equivalent:

dotnet stryker --since --since-target main

CI Integration

GitHub Actions

- name: Run Stryker
  run: dotnet stryker --reporter json --reporter html
  continue-on-error: true

- name: Upload Mutation Report
  uses: actions/upload-artifact@v7
  with:
    name: mutation-report
    path: StrykerOutput/

Azure Pipelines

- script: dotnet stryker --reporter json --reporter html
  displayName: 'Run Mutation Tests'
  continueOnError: true

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'StrykerOutput'
    artifactName: 'MutationReport'

Output Directories

Default output: StrykerOutput/<timestamp>/

Custom output:

dotnet stryker --output ./reports/mutations

Mutation Testing Patterns and Thresholds

Threshold Guidelines

Threshold Levels

Recommended Thresholds by Context

New Critical Code

{
  "thresholds": {
    "high": 90,
    "low": 80,
    "break": 70
  }
}

Established Production Code

{
  "thresholds": {
    "high": 80,
    "low": 60,
    "break": 50
  }
}

Legacy Code Under Improvement

{
  "thresholds": {
    "high": 70,
    "low": 50,
    "break": 30
  }
}

High-Risk Domain Logic

{
  "thresholds": {
    "high": 95,
    "low": 90,
    "break": 85
  }
}

Mutation Score Interpretation

What Mutation Score Means

• 100%: All mutants killed - every code mutation was detected by tests
• 80-99%: Strong test suite - most mutations detected
• 60-79%: Adequate coverage - significant gaps may exist
• 40-59%: Weak coverage - many logic errors could go undetected
• Below 40%: Poor coverage - tests provide minimal fault detection

Survived Mutants

A survived mutant means:

1. A code mutation was made 2. All tests still passed 3. The test suite did not detect the change

Common causes:

• Missing assertions
• Weak assertions (checking only part of behavior)
• Untested edge cases
• Dead code
• Equivalent mutants (mutation produces same behavior)

Scoping Patterns

Focus on Critical Paths

Target high-value code first:

{
  "mutate": [
    "**/Domain/**/*.cs",
    "**/Core/**/*.cs",
    "!**/*Dto.cs",
    "!**/*Config.cs"
  ]
}

Exclude Generated and Trivial Code

{
  "mutate": [
    "**/*.cs",
    "!**/Migrations/**",
    "!**/Generated/**",
    "!**/obj/**",
    "!**/*.Designer.cs",
    "!**/GlobalUsings.cs"
  ]
}

Ignore Low-Value Mutations

{
  "ignore-mutations": [
    "Linq",
    "StringMethod"
  ]
}

Mutation Categories

Arithmetic Mutations

Original: a + b Mutated: a - b, a * b, a / b

Comparison Mutations

Original: a > b Mutated: a >= b, a < b, a == b

Boolean Mutations

Original: true Mutated: false

Original: a && b Mutated: a || b

Equality Mutations

Original: a == b Mutated: a != b

Negation Mutations

Original: !condition Mutated: condition

Block Statement Mutations

Original: if (x) { DoSomething(); } Mutated: if (x) { }

Return Value Mutations

Original: return value; Mutated: return default;

Patterns for Surviving Mutants

Pattern: Missing Boundary Tests

Mutation that survives:

// Original: if (x >= 10)
// Mutated:  if (x > 10)

Fix: Add boundary test for x = 10.

Pattern: Missing Null Checks

Mutation that survives:

// Original: return item ?? default;
// Mutated:  return item;

Fix: Add test for null input.

Pattern: Unchecked Error Paths

Mutation that survives:

// Original: throw new ArgumentException();
// Mutated:  (removed)

Fix: Add test that expects the exception.

Pattern: Side Effect Not Verified

Mutation that survives:

// Original: _logger.Log(message);
// Mutated:  (removed)

Fix: Verify logger was called in test.

Incremental Mutation Testing

Run Only on Changed Code

dotnet stryker --since --since-target main

Configuration for CI

{
  "stryker-config": {
    "since": {
      "enabled": true,
      "target": "main"
    }
  }
}

When to Use Full Mutation Runs

• Before major releases
• After significant refactoring
• When establishing baseline scores
• On scheduled nightly or weekly builds

Performance Optimization

Use Coverage Analysis

{
  "coverage-analysis": "perTest"
}

This tracks which tests cover which code, running only relevant tests per mutant.

Limit Concurrency Based on Resources

{
  "concurrency": 4
}

Higher values use more memory and CPU.

Use Baseline for Large Codebases

{
  "baseline": {
    "enabled": true,
    "provider": "disk",
    "path": ".stryker-baseline"
  }
}

This caches results and only re-runs mutations for changed code.

Anti-Patterns

Do Not Chase 100% Everywhere

Diminishing returns on low-value code. Focus effort on:

• Domain logic
• Business rules
• Critical calculations
• Security-sensitive code

Do Not Ignore Survived Mutants Blindly

Each survived mutant is a potential bug that tests would miss. Investigate before ignoring.

Do Not Run Full Mutation Testing on Every PR

Too slow for large codebases. Use incremental mode or schedule full runs separately.

Do Not Set Break Threshold Too High Initially

Start conservative and increase as test quality improves. A failing mutation gate on every PR creates frustration without value.

Workflow Integration

Recommended PR Workflow

1. Run incremental mutation testing on changed files 2. Report results without failing the build 3. Track trends over time

Recommended Release Workflow

1. Run full mutation testing before release branches 2. Use break threshold to enforce quality gate 3. Generate reports for team review

Recommended Nightly Workflow

1. Run full mutation testing on main branch 2. Generate trend reports 3. Open issues for significant score drops

Stryker.NET

Open/Free Status

• open source
• free to use

Install

dotnet tool install -g stryker

Or as a local tool:

dotnet new tool-manifest
dotnet tool install stryker

Verify First

Before installing, check whether the repo already has a local or global Stryker tool:

rg --files -g '.config/dotnet-tools.json'
dotnet tool list --local
dotnet tool list --global
command -v stryker

Common Usage

dotnet stryker

CI Fit

• best for critical libraries, domain logic, and less frequently changing hotspots
• usually too expensive for the fastest PR gate in large solutions

When Not To Use

• when the test suite is already flaky or too slow
• when simple build, test, and coverage gates are still not stable

Sources

• Stryker.NET