+1, I find it hugely useful to separate tests on a case-by-case bases into fast tests I run locally before git push, and slow tests that are run asynchronously by the merge queue on CI. There’s Pareto principle in play here: 80% of tests finish in 20% of time.
I also found that historically it really wants to be a per-test, rather than a per test-suite thing. Some “unit” tests do combinatorial exploration that needs a lot of CPU time, some integration tests are smoke tests that finish in milliseconds.
I usually filter the two at runtime, by looking at the “RUN_SLOW_TESTS” env variable.
Something like this is close to what I already do, except I construct a filter for the test names at build time. My main problem with it is that there’s no good way with name filtering to exclude tests in some of the codebase and not in others.
I think switching to skipping tests instead of filtering them can solve that, so I’m marking this solved.