4 ms·
I have tried those out for a large Java project. The problem is that it is just too slow to use with a large unit test suite. What mutation testing does, is ru
by misja111 3y ago
I have tried those out for a large Java project. The problem is that it is just too slow to use with a large unit test suite.
What mutation testing does, is running all the tests in your suite multiple times while changing some of your code base ("mutation points") to see if it affects the test outcome (it should).
So say that your test suite normally takes 10 minutes, then a full mutation suite can easily be a factor 50 slower, which means 8 hours.
- jononor 3y agoPerfect for a daily CI job?
- polynomial 3y ago"daily CI"?
- rafaelmn 3y agoPeople tend to use CI as a synonym for automated build pipeline.
- polynomial 3y agoSo I've heard
- wilgertvelinga 3y agoFind ways to reduce those 10 minutes. Some ideas: - make the individual tests run faster - remove obsolete tests - increase parallellism - use a tool that can determine which tests to run based on what has changed, for example nx.dev.
- LadyCailin 3y agoYou don’t block on that, you run it on a continuous loop in a CI. Then, if tests fail, you are limited to the checkins over the last day or whatever, and you can more easily bisect to find the offending PR, and file a bug against that dev to fix, or just revert the change. But you dont run the full suite locally, though there are ways for stryker anyways to only test code that changed, which you can run locally, or in the PR build.
- deleted 3y ago[deleted]