Rerun on save not covering other test files about vitest HOT 14 OPEN

Same goes for checking types using --typecheck option.

from vitest.

I don't understand you issue. Vitest reruns only affected tests on file change, not every test.

from vitest.

I don't understand you issue. Vitest reruns only affected tests on file change, not every test.

Vitest shows that there's only 1 test file on a rerun, which isn't true. If I want to test just that file, I'll specify it when running the command.

from vitest.

From what I can see in the reproduction, this issue is not about running affected tests, but running affected tests and tests that failed before. If I remember correctly, Vitest was running all failing tests plus affected tests before at some point, so this looks like a regression.

What Vitest will not do is run all tests when one test is changed because it doesn't make any sense - the status of all your other tests will not change because test files are isolated.

from vitest.

From what I can see in the reproduction, this issue is not about running affected tests, but running affected tests and tests that failed before. If I remember correctly, Vitest was running all failing tests plus affected tests before at some point, so this looks like a regression.

Yes, thanks, this is kinda what I was trying to convey. Was there a purpose to rerunning non-affected failed tests?

What Vitest will not do is run all tests when one test is changed because it doesn't make any sense - the status of all your other tests will not change because test files are isolated.

Makes sense — the results of the other tests can be reused regardless of their outcome.

from vitest.

Maybe related to this PR?

• #3773

It looks like this PR is introducing "file change -> rerun file change and failed ones"

from vitest.

Is there a flag or is vitest supposed to to always rerun all tests when any test file changes? That's what I've been searching for...

from vitest.

is vitest supposed to to always rerun all tests when any test file changes?

@waynebloss Vitest is not supposed to do this as explained in #4997 (comment)

This is expected to provide a better experience for most of the users, but if this behavior is not preferable for some reason, then it would help if you can share more details about your use case.

As an exception, for example config files change, Vitest should re-run everything and we have forceRerunTriggers for that purpose https://vitest.dev/config/#forcereruntriggers. Maybe this is what you're looking for?

from vitest.

@hi-ogawa Thank you. I am a new user giving vitest a chance after enjoying the use of the excellent vite.

Mainly, I just want to see all the nice check marks (and totals) all of the time. So I am having to use nodemon to work around this currently.

The problem IMO is that the default console output is not stable after a rerun, so you have to scroll back up to history to see results from previous runs. It's also not stable depending on if there is more than one test file or not. (With a single test file, you get sub-check marks for each test in that file but with multiple test files you get no sub-check marks.)

I know this is not the place for this issue and I haven't completely explored all the reporting options yet so perhaps I'll look at those and also give the UI a try.

from vitest.

So, I solved my own related stability issue by just using --reporter=verbose. I guess what I really want is a verbose-caching reporter so I'll be continuing the search...

from vitest.

@hi-ogawa Here is my final report in response to your query:

• I have tried the UI and it is indeed a stable UI. I don't like that you can't see a whole outline of all test files and their tests at once and just scroll up and down to see details. However, more importantly, I really don't want to open yet another window to work with a given project, especially one that also takes up the terminal pane used to start the UI window. As such, I will continue using nodemon + vitest via vitest run --reporter=verbose for now.
• With regards to using forceRerunTriggers, I suppose that I could try to set it to be the same paths as the include files but when I tried that in my vitest.workspace.ts in my repo root I found out forceRerunTriggers is one of the configs that can't be in the workspace file. Even if it worked, it would be smelly IMO. See [0]
  • Also, what if a file that I change modifies some database e.g. a Redis store or some other external thing that isn't a file? I love the simplicity of just re-running all tests, especially at the beginning of a project when the tests all run very quickly.
  • At later stages of a project, I might turn that flag off when I want to focus on a single test file at a time.

So I think a simple flag to allow always rerunning would be useful.

[0]

from vitest.

@waynebloss Thanks for providing the details. It looks like you're feeling some UI/UX issues of builtin reporters, so if you want to expand on that, please feel free to open new issue or use new discussion if it's just a quick question https://github.com/vitest-dev/vitest/discussions

As for forceRerunTriggers, I think your "smelly" one indeed doesn't work since this config has to be defined for "root" config. Also I think having forceRerunTriggers same as include is not enough since I suppose you want to rerun everything when you change any source files (not necessary test files).

In your case, probably forceRerunTriggers: ["**/*"] is what you want. I made an example project here. Could you take a look?

https://stackblitz.com/edit/vitest-dev-vitest-xysf8w?file=vitest.config.ts

from vitest.

@hi-ogawa That works very well, thanks again!

I was also able to avoid creating a separate vite.config.ts file in each of my packages by using the extended workspace definition shown in my previous comment, but without the error shown. Originally to that end, I had tried to put the vite-tsconfig-paths plugins definition code into the root vite.config.ts but that did not work so knowing where a config can go remains somewhat confusing to me.

However, I can get rid of nodemon now and we'll see how that goes. Thank you very much for your help.

from vitest.

As a team, we decided that it would be nice to show previously failed test files in the terminal, but we won't show the errors in those files to not clutter the output. The tests themselves will not be running, unless the change will affect the file.

from vitest.