Tests are most useful when they provide fast access to a code path for repeated testing during development, when the code path would otherwise be far removed fr

Tests are most useful when they provide fast access to a code path for repeated testing during development, when the code path would otherwise be far removed from the normal course of user interaction with the software. This closes the debugging loop while you're developing new features, when it's applicable. The second time, less often, when tests are useful is when making large changes with broad implications, and quickly verifying that everything still works and that you haven't overlooked some subsystem. The least frequently useful application of tests is regression tests. 99 out of 100 regressions only happen once. If you add a regression test, it won't happen again (unless you overlooked something), but it was unlikely to happen again anyway. Generally I write the first category of tests when I feel that it would be useful to solving the problem I'm working on. Then, when I finish the code, I commit the test, because why not? It's written. It'll never fail again, but hey. This creates a reasonably managable collection of tests which, more often than not, test the more complex (and therefore more fragile) parts of the codebase, and are a decent representative sample of all of the subsystems. This provides sufficient test coverage to support the second case. The third case is so rare that it can be addressed on a case-by-case basis. The most stable software is software which doesn't change. Keep your scope small and your complexity low, and don't be afraid to mark a finish line. This is more effective than exhaustive automated testing.