Feature request: run corresponding test file when source file is saved

[joshua-rh]

The two options to autoRun.onSave are "test-file" | "test-src-file".

We have a lot of tests so when set to "test-src-file", this can trigger a performance issues when saving certain files. "test-file" works well but it would be nice if when we saved a src file, it would run the corresponding test file matched by name. e.g. Saving component.tsx would run component.test.tsx if it exists. No worries if it doesn't exist. I know using --findRelatedTests is very smart but it has a performance trade-off.

This could be an additional option like "test-src-file-only" or added onto the "test-file" option.

Environment

1. vscode-jest version: 5.2.3
2. node -v: v16.19.0
3. npm -v or yarn --version: 8.19.3
4. npm ls jest or npm ls react-scripts (if you haven’t ejected): [fill]
5. your vscode-jest settings if customized:

  "jest.autoRun": {
    "watch": false,
    "onSave": "test-file"
  },

6. Operating system: [fill]

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) [fill]

Steps to Reproduce

[fill]

Relevant Debug Info

[fill]

Expected Behavior

[fill]

Actual Behavior

[fill]

---

The fastest (and the most fun) way to resolve the issue is to submit a pull-request yourself. If you are interested, feel free to check out the contribution guide, we look forward to seeing your PR...

[connectdotz]

Interesting use case... I can see why you would want such a feature, but I can also see things might get complicated quickly - for example, maybe only a few files are "high impact", wouldn't it be nice if we could run these files with one test file pattern, while the rest still use the "on-save" pattern...

Therefore, I am wondering, instead of creating a new feature, what if you just toggle autoRun off when you know you will be working around the "high impact" files, otherwise, leave the autoRun to "on-save" or whatever your current configuration is. That way you can fine-tune jest behavior at run time dynamically and easily based on individual preference, instead of changing the settings that most likely would impact every team member and every file. What do you think?