Software development gurus, in a mistaken attempt to simplify things, make up simple rules for us simple people to follow. I think a better approach is giving us the arguments to decide by ourselves on a case-by-case bases how, or if, to use the tool or method in question.Should unit tests be used always and unconditionally?
I have been giving unit tests some thought. Unit tests are a tool and I am not religious about when to apply it. Sometimes I might mock out some external dependencies, but at other times I would like to test that dependency as well. It is often a compromise between complicating the code, and mock out external dependencies. E.g. should I introduce a configuration manager so that I can make the code independent of the database, or should I just include retrieving the configuration from the database in the test? I don't believe in using unit tests all the time, sometimes it is just too difficult to set-up the test. They should be used when the tests need to be repeatable for regression purposes. Sometimes you just know that you are not going to change that piece of code and then it is sufficient, simpler, and faster to test it manually until it works as intended :)
Another issue I have with unit tests is that they can lull one into thinking it is ok to make a change and accept it as good if no red lights appear in the test runner. The correct procedure, however, is to check if there is actually a unit test that covers the code you just changed, because, initially , it might have been deemed not feasible to create unit tests for that particular scenario.
I might be stating the obvious (it is often needed), but unit tests are a tool that should not be applied automatically or relied on blindly :)