Atomicity in Unit Tests

Unit tests can be a touchy subject for some developers.  For some, they dispise doing them at all, while others go completely overboard with them.  I'm in the middle.  I don't believe that they're a cure-all for bad code, but I do feel that whether you call them unit tests or test harnesses, you have to do them to provide a repeatable way to check the stability of your build.

One thing I do have a snit about is the atomicity of those unit tests.  Many developers build unit tests that build upon each other.  It reduces the development time for unit tests but it makes debugging and troubleshooting pure misery for anyone but the original developers.  Also, if you have 100 unit tests and they are all interdependent, then if test # 99 breaks, you still have to run the first 98 just to get to the point where you need to debug.  Again, I don't say that you can't build these types of tests.  For complex systems such as O&E, payroll, D&C type systems, you can't avoid it.  But most systems can have many small standalone unit tests and only 2 or 3 large complex tests like these.

So to make your live easier, try to make your tests as atomic as possible.  That is, make them stand alone and singularly repeatable.  You'll thank yourself later!