jaspervdveen
commented
6 months ago For #4790, this run should be as swift as possible to promptly update the Test Explorer with the latest data on code changes. However, the current process remains too slow to be practical. Following the instrumentation of the code in memory, the project undergoes preprocessing, initializes the checker pool, and sets up the sandbox. None of these steps are necessary to display available mutations in the extension. However, the event is sent and the Stryker process is terminated only after completing them.
I discussed this issue with @danny12321. Some options we discussed are:
- We might not need to this instrumentation only process as a Stryker option. Instead, we only need an event to be sent immediately after the files have been instrumented in memory with the report as the payload. Then if we incorporate support in StrykerJS for real-time reporting, we could send an event to the extension and then instruct the extension to terminate the Stryker child process once the event has been received.
- If we decide against option 1, we can still utilize this feature and allow the IDE extension to override config settings such as the build command, checkers, plugins, etc., to bypass some time-consuming steps.
@nicojs what are your thoughts on this?
This code change implements a Stryker option to stop Stryker after instrumenting the code. When running Stryker with this option enabled, it executes the instrument phase only and the JSON-reporter reports the results as a valid mutation testing elements report. The results of this run can be used for #4779, to display mutations which haven't been tested yet (pending mutations).
Resolves #4790