Show all cases of a parameterized test without having to run the test suites first

[szszoke]

Environment

1. vscode-jest version: 5.0.0
2. node -v: 14.20.1
3. npm -v or yarn --version: 7.24.2
4. npm ls jest or npm ls react-scripts (if you haven’t ejected): [email protected]
5. your vscode-jest settings if customized:
   • jest.autoRun? { "watch": false, "onSave": "test-file", "onStartup": null }
6. Operating system: Dockerized DevContainer on Linux host

Prerequisite

• are you able to run jest test from the command line? [yes
• how do you run your tests from the command line? (for example: npm run test or node_modules/.bin/jest) npm run test

Steps to Reproduce

test.each((1, 2, 3, 4, 5))("test %d", () => {
  // TODO: long running test
});

Expected Behavior

When I open Test Explorer
And no tests have run yet
Then I see five test cases for the parameterized test suite

Actual Behavior

When I open Test Explorer
And no tests have run yet
Then I only one test case for the parameterized test, named test %d

When I run the parameterized test suite
Then the test cases become visible in Test Explorer
And they can be run individually

---

This behavior is not a problem for small tests but becomes quite a chore if the tests are long-running. Is it possible to discover the test cases of a parameterized test suite without running it first?

[connectdotz]

this will be hard... before the test is run, all we have is static analysis, i.e. no interpretation of template-literal or any variable substitutions. Right now I can't think of a way to get the interpreted strings without running the tests...

[szszoke]

Well, ideally jest would provide a way to list them without running the test suites.

Otherwise a hacky solution could be to run the test files with a custom implementation for describe/test, etc. which would collect the test suite descriptions without running the suites. I assume that the extension would still have to replicate the same environment as jest to avoid unexpexted runtime errors.

[connectdotz]

Otherwise a hacky solution could be to run the test files with a custom implementation for describe/test, etc. which would collect the test suite descriptions without running the suites. I assume that the extension would still have to replicate the same environment as jest to avoid unexpexted runtime errors.

Yes, I think you start to see why we did not take that approach. 😉 We should not reinvent the wheel, especially when we are not sure our duplicate effort would be better than the original while diverging from the core competency of this extension...

A workaround is to use a "describe" with static text surrounding the dynamic-titled tests, that way you can still trigger the tests without depending on the dynamic titles to be resolved.

[connectdotz]

close this as currently there is no good alternative without reinventing the wheel. We can revisit if the situation changed.

[connectdotz]

@szsoke you might be interested to know that we made some changes based on your concern regarding not being able to run parameterized tests before running the test suite first. The solution we implemented is to automatically fall back to its parent block. (see #959 )

While it doesn't fully resolve the test names before the run, it should improve the experience quite a bit. Feel free to give the v5 pre-release a spin, and let us know how it works for you. Thanks.