>I generally want all tests in total to complete in a few seconds at most. Longer than that and they become a serious impediment to the edit build test cycle, a

>I generally want all tests in total to complete in a few seconds at most. Longer than that and they become a serious impediment to the edit build test cycle, and you either start screwing around with only running some tests routinely, or only run the tests occasionally, neither of which is good. I don't think that's a problem at all. I usually run one functional test at a time while developing (ideally runtime < 30 seconds) which covers the code that I'm changing. 90% of the bugs that I introduce accidentally will get picked up by that test while I'm refactoring. In the background (often on a different machine) I will have the full set of tests running constantly. Those might take hours to complete (sometimes a whole night). They will pick up the 5-10% of bugs that slipped through the net eventually, though - which is ok. This is way better than having a unit test suite that doesn't even come close to mimicing real life usage, and is a PITA to maintain because it's naturally tightly coupled to your architecture (this bites you back when you refactor). >If a single test takes a few hundred milliseconds then that means you can only run a dozen or so such tests before you hit that problem, which isn't very many. I'd say that a few hundred milliseconds is quite slow in this context. One 500 millisecond test for this particular use case will pick up 90% of bugs. No, that is not going to interrupt your development cycle. Yes, a full suite of tests that fires up a VM for every different possible kind of filesystem will take hours. That's perfectly ok. You can go get a coffee while it runs.