Published: 1 January 2017
Up until now, when you were writing unit tests, you were actually investing in code quality. Catching bugs early by continuously exercising your code with unit tests and keeping your stakeholders happy by presenting them with a code coverage number of 85% or higher. But does code coverage tell the entire story? Are your tests actually able to detect bugs? How do you test your tests? That's the problem mutation testing sets out to solve.
We start out by altering your source code ever so slightly (e.g. turning a
-) and then running your tests to see if they are
resilient to this "mutant". If they are (and they fail), all is fine - the mutant is dead. If they don't, the mutant survived and you have to fix your test.
Stryker began its life as the thesis project of Simon de Lang. After graduating, his thesis tutor Nico Jansen joined him and continued development in the open on GitHub. Since then they had five major releases, improving performance, adding support for the Karma and Mocha test runners, as well as creating a fancy HTML reporter.
Up until now, the two of them did all of this in their own time, next to their daytime jobs as software engineers.
Around came the traditionally slow Christmas time period, allowing a select few of their colleagues at Info Support to join them for 4 days for the Stryker Hackweek 2016.
The whole team enjoyed the experience a lot and had good fun extending Stryker and fixing issues. We mostly concentrated on integrating Stryker with SonarQube, as well as improving the first time usage experience.
All in all we made 47 commits, closed 18 issues, eat 6 kebabs and 4 subway sandwiches! Here's a quick overview of what we did:
The Stryker Hackweek team consisted of (from left to right):