I think... an approach that might work... is testing the immediate unit first (fastest, guess by changed files), then dependent tests you didn't test yet (e.g.,

I think... an approach that might work... is testing the immediate unit first (fastest, guess by changed files), then dependent tests you didn't test yet (e.g., guessing based on imports), then integration tests that use the feature, then full tests (regardless), then fuzzing... order the test by what is likely to fail quickest. you could even have deployed it during the dependent tests (and run the full and fuzz tests overnight), and have it report back that "no, the commit actually didn't pass". or, bonus points, if you just made a new test case as part of a bugfix or regression ticket, it should definitely test that test unit you just modified first. any commit in a tests/ folder or `test_`. I mean... maybe it should be running on your laptop...