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.