I assist with the face to face interview of software engineers at our firm.  One of my favorite questions to ask a candidate is “What is the most important quality a unit test should have?”  I’m surprised at how many times I get a blank stare; I mean I would at least expect something along the lines of “It should test all the code in a given unit” or “It needs to be isolated to only a single unit of code” or some sort of response. 

To me though, the right answer is “The most important quality of a unit test is that it has to be easy to run.” If you ever interview with me at my firm, bonus points for you if you quote my answer back to me. 

Why “easy to run”?  Any thing that takes any sort of effort beyond the ordinary will rapidly become something that the developers don’t do.  We all have impossible deadlines and if we have to wait a half-hour after we make a change while our unit tests run, we’ll quickly figure out some way to avoid running them.  It doesn’t matter if you have the most brilliantly written unit tests in the world and they execute all of the code in the unit in a way that would have made Edsger Dijkstra weep with joy at its elegance; if it’s not run by the developers it’s not doing you any good.  If you’ve mastered dependency injection and all of your unit tests are very flexible so that they can be changed without any effort whatever, it will do you no good if the developers don’t run them because they report lots of false positives that no one has ever troubled to fix.

This is the point—make the unit tests dead simple to execute, make them fast and fix bogus tests.  Anything else you do with your unit tests is wasting your time unless you address these fundamental concerns.