Stryker copies binary file incorrectly : a pptx file (during initial test run)

[edi9999]

Summary

Hello, it seems that the stryker command copies docx/pptx files incorrectly in my project.

It worked before (I can't tell when exactly, and which version I used before, but it worked 1 year ago I think).

Stryker environment

+-- @stryker-mutator/[email protected]
+-- @stryker-mutator/[email protected]

Your Environment

software	version(s)
node	18.17.0
npm	9.6.7
Operating System	Ubuntu 22

Reproduce the issue

git clone https://github.com/open-xml-templating/docxtemplater.git
cd docxtemplater
npm install
npm run test:mutations

You can then view the difference between two files :

$ ls examples/a16-row-id.pptx -lah
-rw-r--r-- 1 edgar edgar 39K Mar  7  2022 examples/a16-row-id.pptx

$ ls .stryker-tmp/sandbox*/examples/a16-row-id.pptx -lah
-rw-r--r-- 1 edgar edgar 64K Aug  3 20:57 .stryker-tmp/sandbox2472055/examples/a16-row-id.pptx

It seems that the copied file differ for some reasons.

[edi9999]

I've just tested this with version 6.4.2 of stryker and it worked well with that version, so I think it has something to do with stryker 7.0

[odinvanderlinden]

@edi9999 thanks for opening an issue. What is the problem you are facing with this bug?

[edi9999]

The problem is that my software relies on some binary files during testing.

Those binary files are "pptx" documents, that need to be copied for the test run.

They are copied, but the contents of the file is incorrect :

As you can see in this output :

$ ls examples/a16-row-id.pptx -lah
-rw-r--r-- 1 edgar edgar 39K Mar  7  2022 examples/a16-row-id.pptx
$ ls .stryker-tmp/sandbox*/examples/a16-row-id.pptx -lah
-rw-r--r-- 1 edgar edgar 64K Aug  3 20:57 .stryker-tmp/sandbox2472055/examples/a16-row-id.pptx

The basefile is 39K big, and the copied file is 64K big, there is probably an encoding issue or something similar.

You can reproduce the issue with following script :

git clone https://github.com/open-xml-templating/docxtemplater.git
cd docxtemplater
npm install
npm run test:mutations

[edi9999]

I've just made a simpler reproduction case with just one single file and one single test file :

To reproduce run :

git clone https://github.com/edi9999/stryker-bug.git
cd stryker-bug
npm install
npm test # works correctly, shows size of 39344
npm run --silent stryker # fails : shows size of 64626

Full stryker output :

$ npm run --silent stryker
22:29:44 (2451263) INFO ProjectReader Found 1 of 7 file(s) to be mutated.
22:29:44 (2451263) INFO Instrumenter Instrumented 1 source file(s) with 9 mutant(s)
22:29:45 (2451263) INFO ConcurrencyTokenProvider Creating 7 test runner process(es).
22:29:46 (2451263) INFO DryRunExecutor Starting initial test run (mocha test runner with "perTest" coverage analysis). This may take a while.
22:29:46 (2451263) ERROR DryRunExecutor One or more tests failed in the initial test run:
        should do x xxx
                Error getting result : 64626
22:29:46 (2451263) ERROR Stryker There were failed tests in the initial test run.

[odinvanderlinden]

Thanks for the extra information, at the moment i don't have time to further investigate this issue. Ill probably take a look Friday next week (15 september)

[nicojs]

The issue is with disableTypeChecks.

As of Stryker 7, the default value for disableTypeChecks changed to true: https://stryker-mutator.io/blog/announcing-stryker-js-7/#-breaking-changes

This means that all files are interpreted as utf-8 by default, also non-ts files.

I think true for disableTypeChecks should only force typescript-looking files to be read using utf-8 encoding: *.ts, *.js, *.tsx, *.jsx, *.mjs, *.mts, *.cts, *.cjs, *.html, *.vue

As a workaround, you can disable type checks in stryker.conf.json:

{
  "disableTypeChecks": false
}

[edi9999]

Thanks a lot for the investigation @nicojs !

It seems to be working indeed !

Not sure to understand what this has to do with types, since docx files are always binary files.

[nicojs]

Exactly. Stryker loads all files from disk and interprets them as UTF-8 just in case it needs to disable type-checking on them later.

This is the bug. It should only interpret actual TS-like code files 🧐