CODEWITHSUNDEEP
typescriptjestjsnestjs
jlar310
jlar310

Reputation: 649

Jest tests failing with ENOENT no such file or directory (referring to the spec files themselves)

We have a NestJS project with several modules. Suddenly, some tests stopped working with errors all like

FAIL libs/backend/nest/pipes/src/lib/iso-date-validation.pipe.spec.ts

● Test suite failed to run

ENOENT: no such file or directory, open D:\git\my-nest-project\libs\backend\nest\pipes\src\lib\iso-date-validation.pipe.spec.ts'

It knows what test to run, but then it claims it can't find the test file. Sometimes we get a couple of these errors, sometimes dozens.

These errors are happening randomly (not always on the same tests) locally on my machine as well as on our Jenkins server and on other developer environments as well. I can reproduce this on Windows/Mac/Linux.

There were no changes to the test or project configuration files that would have triggered this change. In fact, I have checked out previous versions of the codebase that built reliably in Jenkins and now they have the same random test errors.

I have tested on clean nodejs environments with nothing installed globally except npm.

Using the jest --verbose flag gives me no further details.

The jest config in a NestJS project is multi-layered, so it's hard to display the whole thing here, but I don't understand how this could be a configuration issue because the tests used to run fine and the configuration files have not changed.

I have tried clearing the jest cache, but the results are not consistent. On some occasions I can get a clean test run after clearing the cache.

More often than not, the test failures occur in a module that has some React .tsx templates, but not always. Sometimes a pure Typescript module will fail.

Upvotes: 9

Views: 12171

Answers (2)

Embedded_Mugs
Embedded_Mugs

Reputation: 2426

Canceling the test watch and restarting it worked for me. with Ctrl-D then npm test

Upvotes: 3

jlar310
jlar310

Reputation: 649

It turns out I shot myself in the foot on this one, but I'm posting the answer in case it helps anyone else.

Some of our jest tests were using the mock-fs package to simulate a path to a managed config file that is present in the production environment. But the tests that used mock-fs neglected to call mock.restore() after the test to disable the mock file system. Apparently the mock file system is quite invasive. What was strange was that introducing mock-fs did not immediately produce the unexpected behavior of breaking other tests. It was also quite unexpected that mock-fs could break jest itself.

https://www.npmjs.com/package/mock-fs

RTFM

Upvotes: 11

Related Questions