Add testNamePattern to Project.Config

[ryparker]

Summary

This is a working solution for my feature request. Ultimately this PR was created to enable custom Jest runners the ability to control what test cases of a test file run. This PR adds the testNamePattern to the Project.Config options and exposes the globalConfig.

Test plan

It looks like some tests were already failing on master's head. 20 snapshots need to be updated. I also noticed after running the tests that it updated several yarn.lock in the e2e/ dir. I'm more than happy to add tests however I may need some direction on the currently failing tests.

TODO

• Update CHANGELOG.md
• Update Project.Config website documentation
• Create Jest-Runner README
• Resolve failing tests (not-PR-related)
• Add tests

[facebook-github-bot]

Hi @ryparker!

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[SimenB]

@ryparker yarn.lock noise should be fixed on master now. Not sure about the failing tests you mention - as you can see CI is green here.

---

That said, I'm not sure about the approach this PR makes. I think it makes more sense for a runner to be able to filter tests more directly, e.g. by getting a list of all test cases and returning the list of which to run rather than using testNamePattern.

@jeysal @thymikee @cpojer thoughts?

[ryparker]

@ryparker yarn.lock noise should be fixed on master now. Not sure about the failing tests you mention - as you can see CI is green here.

That said, I'm not sure about the approach this PR makes. I think it makes more sense for a runner to be able to filter tests more directly, e.g. by getting a list of all test cases and returning the list of which to run rather than using testNamePattern.

@jeysal @thymikee @cpojer thoughts?

Thanks for resolving those yarn.lock files. Locally I'm noticing module errors. I think this is related to yarn v2 and I've noticed it happens with both my fork and a direct clone of the Jest repo (w/o my changes).

➜ npx envinfo --preset jest

  System:
    OS: macOS 10.15.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Binaries:
    Node: 14.4.0 - ~/.nvm/versions/node/v14.4.0/bin/node
    Yarn: 2.1.1-git.20200730.c077b96d - ~/.yarn/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v14.4.0/bin/npm
  npmPackages:
    jest: workspace:packages/jest => 26.2.2 

Commands:

1. yarn install
2. yarn build
3. yarn test

Result:

Is there a yarn v2 step that i'm missing which maybe links the local modules?

Once I can get these tests resolved, I'd be happy to go in another direction. If you'd rather see test cases handled similar to the TestRunner.runTests() method. It will require more changes to the test framework. I can start by making a prototype of how this might be implemented with Jest-Circus and see what you guys think.

[jeysal]

I would agree with Simen that putting this in the config is not the way to go. I also suspect that runners can already do this because they control the environment and test framework - they can execute a forked/modified version of the test framework, or perhaps even use the environment's test event handling to modify the behavior of test case declarations

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.