+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.