Automating unit testing is difficult but that’s no excuse
In this short article Rob Diana argues that developers are responsible for producing working code and that to do so, it is imperative that the code gets tested and exercised through unit tests.
This is perfectly reasonable and most developers I worked with don't have any issue with unit testing as defined by Wikipedia as long as the level of automation is low or non-existent. The Wikipedia article on unit testing explains that "[unit testing] implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation."
However, a major gap exists between exercising the code through manual or semi-automatic tests and writing automatic tests to verify continuous integration builds. Of course the latter produce higher quality software in the long run but this gap prevents some teams from reaching a higher level of code quality while minimizing rework (i.e. higher productivity).
Implementing automated unit tests is not simply a technical exercise. It is also a complex problem that requires a sophisticated and coordinated effort among developers accompanied by a culture change where developers and other stakeholders:
- treat unit testing code with the same level of respect as the rest of the application (this code may not end up on the server or the user's desk put it is an essential element in minimizing defect escape rate);
- accept that an automated build is successful, if and only if, all the associated unit tests passed.
This combination of cultural and technical changes is essential to a successful and full-scale automated unit testing implementation.
Unit Testing as the Last Resort for Code Verification?
This seems counter intuitive to me and to the Test Driven Development philosophy but this article from Dr. Dobbs Code Talk states that there are far more effective techniques for Code Verification than Unit Testing. I let you judge.
[via Dr. Dobbs Code Talk]