There is an interesting post from Andrejs Doronins on LinkedIn about improving test performance:
I replied and added my own comments below:
Remember though, that execution time is trivial compared to development, maintenance, and debugging.
So if you’re adding what seems like extra effort that slows down execution to have a clean environment and setup each time — the savings on reliable tests that pass consistently and find errors that tests that don’t “start from scratch” won’t find is so much greater.
That said — you can be smart in your initialization.
Things like initializing your database with common data only once before a test run, instead of on every test case. Or modifying environment configuration only for a specific suite that needs it can save valuable time compared to doing it for each test.
But this optimizations are sometimes not apparent when you write the tests — or may only apply to 1 test at first, and only become generalized as your test coverage grows.
The trouble here is, that rarely do you have time to go back and review working tests or a test framework to consider how you could optimize.
In this regard, once again, test code imitates production code.
Fijiaaron 