> Markdown version of [/videos/703-mutation-testing-and-fuzzing-in-c?t=248](https://www.wearedevelopers.com/videos/703-mutation-testing-and-fuzzing-in-c?t=248). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Mutation Testing and Fuzzing in C#

Standard code coverage is a deceptive numbers game. Expose weak unit tests by intentionally injecting mutations into your C# code. Discover how fuzzing builds truly resilient applications.

- **Speakers:** Michael Contento
- **Event:** World Congress 2023
- **Published:** September 27, 2023
- **Duration:** 29:28
- **URL:** https://www.wearedevelopers.com/videos/703-mutation-testing-and-fuzzing-in-c

## Summary

The presentation explores advanced software testing strategies in C# to move beyond standard code coverage metrics—which often become arbitrary numbers games—by introducing mutation testing and fuzzing. Traditional coverage metrics like function, statement, and branch coverage only confirm that code was executed, not whether the tests genuinely validate the underlying logic. To build a more resilient testing safety net, developers can leverage mutation testing, which flips the traditional paradigm by actively introducing bugs (mutations) into the source code to see if existing unit tests catch them.

Using Stryker, a simple-to-install CLI tool for .NET, developers can automatically generate an army of code anomalies—such as swapped arithmetic operators, inverted LINQ expressions, or altered regex groups. Stryker generates comprehensive HTML reports showing the ratio of "killed" to "survived" mutants, offering clear, actionable feedback to pinpoint weak assertions. Because Stryker adds execution time to the testing suite, teams should strategically integrate it into their CI/CD pipelines, such as running it before merging pull requests rather than on every commit to maintain a fast feedback cycle.

The session then transitions to coverage-guided fuzzing using American Fuzzy Lop (AFL) bridged by SharpFuzz. Instead of relying on purely random data, this technique mutates valid seed inputs (like XML or HTML files) and uses code instrumentation to track execution paths systematically. By intelligently generating malicious inputs that trigger new code branches, it discovers unexpected edge cases and unintended hard crashes. While fuzzing demands higher initial setup—such as isolating specific entry points and whitelisting intended runtime exceptions—it serves as a highly effective supplement to mutation testing, ensuring robust application behavior against chaotic inputs.

**Keywords:** mutation testing c#, fuzzing application frameworks, stryker .net mutation testing, american fuzzy lop afl, sharpfuzz integration, coverage-guided fuzzing, code coverage limitations, branch and condition coverage, mutating source code logic, ci/cd test pipeline integration, unintended application crashes, software safety net strategies, c# unit test quality, linq expression mutations, regex mutation testing

## Chapters

1. **Analyzing different code coverage metrics and limitations** (00:03) — Traditional code coverage metrics often fail to guarantee that software test suites actually verify logical correctness.
1. **Evaluating test suite quality using mutation testing** (04:08) — Introducing artificial bugs into application source code reveals hidden gaps in unit test assertions.
1. **Automating application mutation testing with the Stryker tool** (07:59) — The Stryker CLI automatically generates code mutations and provides actionable HTML reports on surviving bugs.
1. **Strategies for generating variations of application code** (12:29) — Tools alter arithmetic operators, logical conditions, and LINQ expressions to ensure tests catch inverted logic.
1. **Sending malformed inputs to applications using fuzzing** (15:54) — Fuzz testing relies on feeding repeatedly mutated or randomized data inputs to expose unexpected application crashes.
1. **Tracking execution paths with coverage-guided fuzzing** (19:47) — Application instrumentation tracks code execution depth to intelligently generate new inputs that reach unverified paths.
1. **Implementing American Fuzzy Lop for C# applications** (21:46) — The SharpFuzz library bridges C# code with the AFL tool to create explicit entry points for continuous edge-case discovery.
1. **Integrating mutation testing and fuzzing into software workflows** (25:47) — Running comprehensive mutation tests and fuzzers impacts feedback cycles and often requires specific integration strategies in continuous delivery pipelines.

## Related Moments

- [Exploring advanced security tooling and community dependency vetting](https://www.wearedevelopers.com/videos/1041-reviewing-3rd-party-library-security-easily-using-openssf-scorecard) (from "Reviewing 3rd party library security easily using OpenSSF Scorecard")
- [Evaluating automated approaches for generating unit test cases](https://www.wearedevelopers.com/videos/85-how-will-artificial-intelligence-change-the-future-of-software-testing) (from "How will artificial intelligence change the future of software testing?")
- [Identifying underlying Node.js runtime vulnerabilities using fuzzing tools](https://www.wearedevelopers.com/videos/716-hack-proof-the-node-js-runtime-the-mechanics-and-defense-of-path-traversal-attacks) (from "Hack-Proof The Node.js runtime: The Mechanics and Defense of Path Traversal Attacks")
- [Detecting hidden behavioral flaws using runtime dynamic analysis](https://www.wearedevelopers.com/videos/1568-why-security-first-development-helps-you-ship-better-software-faster) (from "Why Security-First Development Helps You Ship Better Software Faster")
- [Evaluating test suite quality through mutation testing](https://www.wearedevelopers.com/videos/977-test-reduction-doing-more-with-less) (from "Test-reduction - Doing more with less")
- [Addressing questions on development practices and testing strategies](https://www.wearedevelopers.com/videos/1069-100-times-more-frequent-deployments-how-did-we-create-a-high-performance-team) (from "100 times more frequent deployments: How did we create a high performance team?")

## Related Articles

- [Dev Digest 138 - Are you secure about this?](https://www.wearedevelopers.com/magazine/486-dev-digest-138-are-you-secure-about-this)
- [Dev Digest 134 - Where pixels sing?](https://www.wearedevelopers.com/magazine/477-dev-digest-134-where-pixels-sing)
- [Dev Digest 122 - Cracks in the polyfill](https://www.wearedevelopers.com/magazine/457-dev-digest-122-cracks-in-the-polyfill)
- [Dev Digest 131 - AI'm not sure about OSS](https://www.wearedevelopers.com/magazine/472-dev-digest-131-ai-m-not-sure-about-oss)

## Related Jobs

- [Engineer, Offensive Security Organization](https://www.wearedevelopers.com/jobs/ext/1992296-engineer-offensive-security-organization) at **Twilio**
- [Staff Engineer - Offensive Security](https://www.wearedevelopers.com/jobs/ext/1226927-staff-engineer-offensive-security) at **Twilio**
- [Staff Developer Advocate, GitHub Security Lab](https://www.wearedevelopers.com/jobs/ext/1921051-staff-developer-advocate-github-security-lab) at **GitHub**
- [Senior Software Engineer, Fraud](https://www.wearedevelopers.com/jobs/ext/1280398-senior-software-engineer-fraud) at **Twilio**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**
- [Machine Learning Engineer](https://www.wearedevelopers.com/jobs/ext/1597388-machine-learning-engineer) at **ZEISS Group**