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.

Be Sociable, Share!

• 

Related posts:

1. Unit Testing as the Last Resort for Code Verification?