feat(reload test environment): implement test environment reload

[nicojs]

Add the ability for Stryker to restart a test runner in order to reload its test environment. This is used to test static mutants where the test runner is incapable of reloading the test environment by itself. This is a requirement to support es modules (ESM) since it is impossible to reload an ESM using something like delete require.cache['...']. Instead, Stryker will restart the entire test runner process for those mutants.

The way for the test runner to communicate to Stryker whether it is capable of reloading the environment is by implementing the new capabilities() method.

capabilities() {
  return { reloadEnvironment: true }
}

If you do this, you can expect the new reloadEnvironment boolean in your MutantRunOptions to be true when you need to reload the test environment after activating the mutant.

See #2413 and #2922

I also moved some code around (from the MutationTestProcess to a new class MutantTestPlanner).

BREAKING CHANGE: Test runner plugins must provide TestRunnerCapabilities by implementing the capabilities method.

[nicojs]

@simondel do you think it is OK to make capabilities() required?

[nicojs]

This change also contains a breaking change for the reporter API:

- export type MutantTestCoverage = Mutant &
-  Pick<schema.MutantResult, 'coveredBy' | 'static'> & {
-    estimatedNetTime: number;
-    hitCount?: number;
-    testFilter: string[] | undefined;
-  };
+ export type MutantTestCoverage = Mutant & Pick<schema.MutantResult, 'coveredBy' | 'static'>;

I've removed estimatedNetTime, hitCount, and testFilter. They weren't used by our reporters and they were only there to pass along state internally in core, between the find-mutant-test-coverage and mutation-test-executor. I found this very obfuscated and it frustrated me.

That's why I now choose to do all the work in the new MutantTestPlanner class. It is responsible for planning which mutant should be run with which options and which should be reported as an early result.

We can in a later PR replace the onAllMutantsMatchedWithTests with a new onMutantPlanDetermined, which can include the run options per test. That way we can improve the progess reporter. Instead of counting the same progress per mutant, it can count mutants that require a test env reload 3 times for example.

I want to document the breaking in change in that PR, so we don't get a big mess in our changelog.

[simondel]

Nitpicking, but I like mutantTestPlans.map(testPlan => testPlan.mutant) more

[nicojs]

Indeed, a nitpick 😉

[simondel]

It might be nice to have a factory/create method for these MutantTestPlan objects because current function is quite long

[nicojs]

Sure thing

[nicojs]

I've created factory methods for early result as well as for mutant plan

[simondel]

Isn't this just a reduce function?

[nicojs]

Yes, but it is called with both a Set as an Array. I didn't want to create a bogus array just to be able to call reduce. This is better.

[simondel]

Isn't this just a map function?

[nicojs]

Same as above. Note that reduce and map might be coming to Iterables in an ES specification near you: https://github.com/tc39/proposal-collection-methods#proposal