Stryker 0.34 is here. This new version comes with features to help you get started. It's never been this easy to mutation test your JS project!
Install Stryker via the command line:
npm i stryker stryker-api --save-dev
stryker init in the root of your project:
npx stryker init
Some features we want to talk about:
Command test runner
Stryker always was and always will be test runner agnostic. It doesn't care which test runner you use.
However, it always required you to install a test runner plugin.
Are you using Jest? Install the 'stryker-jest-runner'. Want to use mocha? Then the 'stryker-mocha-runner' is just what you need.
This works great if the test runner of choice is supported, but what do you do when your test runner isn't supported?
Like Ava.js or node-tap
or Intern or
maybe you have a custom
npm test command. This is why we've added the
'command' test runner.
Configure it in your stryker configuration:
// Or leave out testRunner, 'command' is the default test runner
command: 'npm run mocha' // optionally choose a different command to run
Stryker ships with the command test runner, so it doesn't need additional plugins. The command test runner will simply run your
npm test script.
If the exit code is
0, the tests succeeded. If not, they failed.
Stryker is limited in the ways it can optimize for performance. For example, it starts a fresh node process for each test run. So if your test runner is supported via a test runner plugin, that would still be the way to go.
The command test runner runs
npm test by default. You can configure a different command with the
commandRunner configuration key.
Special thanks to Diego R.B. for inspiring us to implement this.
Stryker now chooses sensible defaults for all settings. Meaning that you can now run Stryker without any configuration.
It will look for *.js files to mutate in your
lib directories (excluding obvious test files, like app.spec.js).
Coverage analysis will be turned off and the command test runner is used.
npm install --save-dev stryker stryker-api
npx stryker run
Note: The default mutator Stryker uses will still be the deprecated
es5 mutator (comes with Stryker). In time, we'll be migrating this to
With these defaults in place, it is now also easy to run Stryker without a configuration file if you want just one or two config options to change. For example:
Again, special thanks to Diego R.B. for inspiring us to implement this.
With this feature in place, Stryker is now effectively a drop in replacement for mutode.
stryker init (either using the stryker-cli, or using
npx stryker init)
you can initialize Stryker in your repository. It asks questions via a questionnaire, like "Which test runner do you want to use?" and
"Which test framework do you want to use?". Sometimes you might not know the answer to those questions. It also might take a lot more
configuration to get you started. This is why we added a guides section to the stryker handbook.
We've now integrated those into the
stryker init command.
$ stryker init
? Are you using one of these frameworks? Then select a preset configuration. (Use arrow keys)
Choosing for a preset immediately gets you started! It creates the configuration file and installs the correct plugins.
None/other here will still take you to the normal questionnaire.
Special thanks to wmaarts for adding this feature.
Web component tester plugin
With this release of Stryker, we've also released version 0.1.0 of the stryker-wct-runner. Install it with:
$ npm install --save-dev stryker-wct-runner
Configure it with:
With this plugin, we now support Polymer cli projects. The web-component-tester runs your tests in an actual browser. However, it doesn't support any of the coverage analysis performance features for now. If you want those to be supported, please open an issue. You're also welcome to take a look at the issues we've opened at Polymer side. Any help there is really appreciated.
We're still focussing on getting v1 out of the door. We're reasonably certain it will happen in Q1 of next year. V1 will mostly be removing deprecated features. We'll also introduce a more predictable release schedule with strict Semantic Versioning policies. Stay tuned.
Input on these new features or the v1 preparations are welcome!