Gutenberg: Jest tests don't run when `/wordpress/` is somewhere in project path

Created on 16 Feb 2020  Â·  3Comments  Â·  Source: WordPress/gutenberg

Describe the bug

The Jest config includes /wordpress/ in the testPathIgnorePatterns array. As a result, when your project directory contains /wordpress/ anywhere in its path, no tests are detected. I use wp-local-docker, which installs sites into a wordpress directory. This is what I see in the terminal when running npm run test-unit:

No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In /Users/my-user/wp-local-docker-sites/jw-test/wordpress/wp-content/plugins/gutenberg
  5977 files checked.
  testMatch: **/__tests__/**/*.[jt]s, **/test/*.[jt]s, **/?(*.)test.[jt]s - 459 matches
  testPathIgnorePatterns: /.git/, /node_modules/, /packages/e2e-tests, /wordpress/, /Users/my-user/wp-local-docker-sites/jw-test/wordpress/wp-content/plugins/gutenberg/.*/build/, /Users/my-user/wp-local-docker-sites/jw-test/wordpress/wp-content/plugins/gutenberg/.*/build-module/, /Users/my-user/wp-local-docker-sites/jw-test/wordpress/wp-content/plugins/gutenberg/.+.native.js$ - 0 matches
  testRegex:  - 0 matches

Tests run when I comment out the /wordpress/ line.

I'm pretty sure that changing the line to <rootDir>/wordpress/ would fix it, but I'm not submitting a PR because I'm not sure of the rationale for having /wordpress/ in the ignore patterns in the first place. I've tried npm env install and related commands and haven't seen that they add /wordpress/ in the plugin root, but I might be missing something.

This PR diff shows the several places where /wordpress/ is in a Jest ignore patterns array: https://github.com/WordPress/gutenberg/pull/17296/files

To reproduce
Steps to reproduce the behavior:

  1. Put this plugin in any location that has /wordpress/ somewhere in the path.
  2. Run npm run test-unit.
  3. No tests run.

Expected behavior

Tests should be detected even if the project lives where /wordpress/ is in the path.

Desktop (please complete the following information):

  • OS: Mac OS
Automated Testing Good First Issue [Package] Scripts [Status] In Progress [Type] Bug

Most helpful comment

Hi @johnwatkins0. An older local environment for Gutenberg had an option for the WordPress codebase to be placed at <rootDir>/wordpress/. It was handy for changing variables like SCRIPT_DEBUG easily.

That's no longer available now, and as far as I know none of the newer docker environments (env and wp-env) install WordPress at that location. I think it'd be ok to remove this line in the ignore files if you wanted to put together a PR.

All 3 comments

Hi @johnwatkins0. An older local environment for Gutenberg had an option for the WordPress codebase to be placed at <rootDir>/wordpress/. It was handy for changing variables like SCRIPT_DEBUG easily.

That's no longer available now, and as far as I know none of the newer docker environments (env and wp-env) install WordPress at that location. I think it'd be ok to remove this line in the ignore files if you wanted to put together a PR.

I thought I would add a note that I ran into this too and it wasn't very obvious what was happening and was a bit frustrating. I see #20270, but I am not sure what the process is for deprecating wp-scripts env or how long that might take?

I ended up changing test/unit/jest.config.js to only exclude <rootdir>/wordpress/ which seemed to work and would still exclude the old setup. If we did that then wp-scripts env could still be deprecated and it removed completely later? I'm not sure if that is possible in all the other config files or not, but it might be a way to get a fix out faster?

I can work on PR if it seems to make sense, but if deprecating wp-scripts env is relatively easy than it probably isn't worth it, thoughts @gziolo?

I can work on PR if it seems to make sense, but if deprecating wp-scripts env is relatively easy than it probably isn't worth it, thoughts @gziolo?

@brentswisher – I landed your PR as it seems like a good temporary solution that better fits the original use case, but it doesn't fully address the issue described. All the refactoring to deprecate wp-scripts env might take some time as there might be a few unexpected roadblocks discovered 😅

Was this page helpful?
0 / 5 - 0 ratings

Related issues

franz-josef-kaiser picture franz-josef-kaiser  Â·  3Comments

BE-Webdesign picture BE-Webdesign  Â·  3Comments

youknowriad picture youknowriad  Â·  3Comments

aaronjorbin picture aaronjorbin  Â·  3Comments

JohnPixle picture JohnPixle  Â·  3Comments