> Tests are not supposed to be written with speed in mind. There's always extremes. If people write tests with no regard for speed (as I've seen) you can have

> Tests are not supposed to be written with speed in mind. There's always extremes. If people write tests with no regard for speed (as I've seen) you can have "unit-tests" run for 45 minutes before completing. That might be OK to guard against regressions on a nightly-build, but it will in no way be a test-suite I'm willing to running prior to every commit I ship. If the test-suite runs in less than a minute, I'm much more willing to do so before submitting code, and in that way avoiding regressions which needs to be fixed later on. If the tests runs in less than 10 seconds, I'm probably going to run them for every major change I do, even if I'm not planning on submitting anything yet, just for peace of mind. There's IDEs where tests can be run automatically in the background as you make changes and let you know the second you broke something. For that to work efficiently, your tests has to be sufficiently fast. So maybe the aim shouldn't be that tests must be fast above everything else. But if the test-suite can be run quickly and casually, it's value will increase tremendously.