jest: jest cannot find tests when projects are defined in configuration
🐛 Bug Report
Basically I got a bunch of files for my Electron app, some of them require a node environment, and some of them jsdom, because I need to test out some features of my React components, e.g componentDidMount
methods, but I can’t define different jest
configs for my folders, as shown per documentation in jest as it resolves to no tests found.
To Reproduce
You can reproduce the error if you try to run the tests from https://github.com/marcus-sa/venobo/tree/ts
{
"verbose": true,
"moduleFileExtensions": [
"js",
"ts",
"tsx",
"json",
"node"
],
"testPathIgnorePatterns": [
"/node_modules/"
],
"collectCoverage": true,
"transform": {
"^.+\\.tsx?$": "ts-jest"
},
"projects": [{
"testEnvironment": "jsdom",
"testMatch": [
"**/*.test.tsx"
],
"setupTestFrameworkScriptFile": "./setupTests.ts"
}, {
"testEnvironment": "node",
"testMatch": [
"**/*.test.ts"
]
}]
},
as you can see here
In /home/sentinel/Git/venobo
10 files checked.
testMatch: **/*.test.tsx - 0 matches
testPathIgnorePatterns: /node_modules/ - 10 matches
In /home/sentinel/Git/venobo
10 files checked.
testMatch: **/*.test.ts - 0 matches
testPathIgnorePatterns: /node_modules/ - 10 matches
Pattern: - 0 matches
but it works fine if I do this:
"jest": {
"testEnvironment": "node",
"verbose": true,
"moduleFileExtensions": [
"js",
"ts",
"tsx",
"json",
"node"
],
"testPathIgnorePatterns": [
"/node_modules/"
],
"collectCoverage": true,
"transform": {
"^.+\\.tsx?$": "ts-jest"
},
"setupTestFrameworkScriptFile": "./setupTests.ts",
"testMatch": [
"**/*.test.ts"
]
},
System:
OS: Linux 4.13 Ubuntu 17.10 (Artful Aardvark)
CPU: x64 AMD Ryzen 7 1800X Eight-Core Processor
Binaries:
Node: 9.11.1 - /usr/local/bin/node
Yarn: 1.7.0 - ~/.yarn/bin/yarn
npm: 5.6.0 - /usr/local/bin/npm
npmPackages:
@types/jest: ^23.1.0 => 23.1.0
jest: ^23.1.0 => 23.1.0
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 16
- Comments: 22
After searching a while I found out that if you use:
but don’t have one of those folders everything else is ignored too.
In my case jest checks recursively but still doesn’t find any test files. The only difference between your and my config is that I use
<rootDir>
in the testMatch optionDeleting it doesn’t change anything.
Maybe it’s somehow connected with #6546
When I run test with jest I get an error that no test is found both my tests and js files are inside the static folder
Here is my package json
Error
What could be the issue
Thanks !! I was quite frustrated with issue, and it resolved it quite nicely…
EDIT: I fixed it by adding a
WORKDIR
in my Dockerfile. Some other stuff in the root (added by codeship) seems to have interfered with Jest’s regex matching pattern somehow.I got this issue, but only in CI (inside a docker container with NODE_ENV=test and --ci tag)
Using CRA with TS. No idea why its not finding the test. They are clearly there
@y4nnick I did manage to get this set up eventually. It was a royal pain though. My main Jest config looks like:
And within each package subdirectory I have a Jest config that looks more like:
I think it was the
rootDir
being different between top level and each package might have fooled me. Anyway, I got it working, more or less.npx jest
works, as doesnpx jest --projects packages/xxxx
. This was using Jest 24.1.0.Yes, this is still an issue for me too. Right now, projects don’t seem to be useful. I can run a command like:
When
/Users/stuart/git/api-server/__tests__
definitely does contain a whole bunch of*.js
files.More documentation might help, but I’m sure there’s something else skewed too.
I have the same problem as you. All jest versions 23.0.0, 23.1.0, 23.20 don’t detect my tests.
This fixed it for me. Issue seems to be that the recursion is relative to the rootDir path.
Depends how nested your configuration file is, but basically you just need to set your root up as far as you need to go.
I suspect this might be a bug in how jest resolves the config file location, as least in mono repos where you have:
Where the root
jest.config.js
containsprojects
configured using an object, and the individual packages use justjest
as theirtest
command (orjest --selectProjects foo
for packagefoo
). Runningnpm exec -- jest --showConfig
from thepackages/foo
directory, the config ends up being the default configuration for jest, instead of what is in../../jest.config.js
I added some tracing into https://github.com/facebook/jest/blob/main/packages/jest-config/src/resolveConfigPath.ts and found that it is trying to recurse up to the parent directories, but it fails to actually recurse upwards due to https://github.com/facebook/jest/blob/main/packages/jest-config/src/resolveConfigPath.ts#L60 not being the parent directory.
Before and after changing that line to
path().dirname(absolutePath)
, with logs on the arguments ofresolveConfigPath
andresolveConfigPathByTraversing
, I get the following:Before:
After:
As you can see, in the before the directory it tries to load configuration from doesn’t change, despite attempting to recurse upwards. After the change, it correctly tries to load configuration from each of the parent directories.
Note: the
package.json
in/<project>/packages/foo/
does not includejest
configuration (nojest
key)I’m going to try to write tests and a PR to fix the behaviour, though I’m not sure if this’ll break things at all.
Edit: clarified the found
jest.config.js
filename, in my project I’m using typescript, so had accidentally left the.ts
extension, but it’s the same thing either way.Any updates on this?
The problem is that it doesn’t recursively check all directories for tests in my project(s). Before it would check 62 files, but using this configuration it only checks 10 files. I’m unsure whether or not it’s even the root directory it’s checking or what else. There should really be some better configuration documentation for this library.
I ended up working around it by using 2 separate jest configs and one as base.
jest.base.config.js
jest.jsdom.config.js
jest.node.config.js
OFFT: Also the
testRegex
&testMatch
properties aren’t getting resolved properly relatively to yourrootDir
aswell. So. Many. Errors.