Fastest Way to Understand Stryker

FASTEST WAY TO UNDERSTAND STRYKER

We'll create:

Console App
   ↓
Class Library
   ↓
Unit Test Project
   ↓
Run Stryker

You’ll understand:

• solution structure
• testing flow
• mutation testing
• enterprise-level quality tooling

---

STEP 1 - Create Solution

Open terminal:

mkdir StrykerDemo
cd StrykerDemo

dotnet new sln

---

STEP 2 - Create Class Library

This contains business logic.

dotnet new classlib -n StrykerDemo.Core

Add to solution:

dotnet sln add StrykerDemo.Core

---

STEP 3 - Create Test Project

Use xUnit.

dotnet new xunit -n StrykerDemo.Tests

Add to solution:

dotnet sln add StrykerDemo.Tests

Reference Core project:

dotnet add StrykerDemo.Tests reference StrykerDemo.Core

---

STEP 4 - Create Actual Logic

Inside:

StrykerDemo.Core

Create:

namespace StrykerDemo.Core;

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

---

STEP 5 - Create Unit Test

Inside test project:

using StrykerDemo.Core;

namespace StrykerDemo.Tests;

public class CalculatorTests
{
    [Fact]
    public void Add_Should_Return_Correct_Value()
    {
        var calculator = new Calculator();

        var result = calculator.Add(2, 3);

        Assert.Equal(5, result);
    }
}

---

STEP 6 - Verify Tests

Run:

dotnet test

You should see:

Passed!

---

STEP 7 - Install Stryker

Install globally:

dotnet tool install -g dotnet-stryker

Verify:

dotnet stryker --version

---

STEP 8 — RUN STRYKER

Go to test project:

cd StrykerDemo.Tests

Run:

dotnet stryker

---

WHAT HAPPENS NOW

Stryker will:

• Find your code
• Mutate it
• Run tests repeatedly

Example mutation:

Original:

a + b

Mutated:

a - b

Your test expects:

5

Mutated result:

-1

Test fails.

Mutation killed ✅

---

NOW LET’S SEE A SURVIVING MUTATION

Change test to weak test:

Assert.True(result > 0);

instead of:

Assert.Equal(5, result);

Now rerun Stryker.

Some mutations may survive because:

• subtraction may still return positive
• your assertion is too generic

THIS is where mutation testing becomes powerful.

---

THE BIG ENTERPRISE INSIGHT

In real enterprise systems:

• code coverage can say 90%
• but mutation score may say 40%

Meaning:

tests execute code but don’t truly verify behavior.

That’s why mature engineering teams use:

• unit tests
• integration tests
• mutation testing
• quality gates in CI/CD

---

HOW THIS LOOKS IN GITHUB

Usually:

GitHub Actions
    ↓
dotnet test
    ↓
dotnet stryker
    ↓
Fail pipeline if mutation score low

This is where you begin seeing:

• real engineering ownership
• architecture visibility
• DevOps quality flow
• not just user story implementation

---

WHAT YOU SHOULD DO NEXT

After this basic example:

1. Add more methods
2. Add edge cases
3. Purposely create weak tests
4. Watch mutations survive
5. Improve tests
6. Re-run Stryker That loop teaches more than tutorials.

---