"Run fewer tests!", as the article mentions, is a great idea, but the existing ways of doing this are suboptimal. Failing fast usually stops at the first faile

"Run fewer tests!", as the article mentions, is a great idea, but the existing ways of doing this are suboptimal. Failing fast usually stops at the first failed test, and provides a quick binary pass/fail signal (especially if tests are ordered based on historical failure rates). The downside is losing information if there would have been multiple failures. If you have multiple cycles of failure->fix bug->push PR->different failure->fix new bug->push PR, that can wipe out any time savings. Running specific suites that are subsets of all tests cuts down on the number of tests run, at the cost of both under- and over-testing, as well as setting up and maintaining the suites. E.g., under-testing is when a relevant test wasn't in the suite you ran, over-testing is when you run a test that cannot be affected by your recent code changes. ---- Much better is to use "Test Impact Analysis" (TIA). In short, statically analyze the code (using file dependencies, program dependency graph, coverage, etc) and skip all tests that you can prove are irrelevant. The savings depends on the dependency layout of your code, and the size and nature of your PR, but it can be really high, as much as 90% for a small PR with a well-structured code base. MS pioneered TIA a couple decades ago, but outside MS/Azure, it's surprisingly not that common, despite some major advantages. I know of the occasional test plugin doing it, and one dead startup (YourBase), but that's it. If anyone's interested in such a thing for Python, I'm launching a tool soon for it: https://getspdr.dev https://getspdr.dev.