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.

Daily stand-up meetings are at the core of the Scrum process. They help synchronize the team and quickly escalate impediments. Regardless if you have been participating in those meetings for years or you are just starting today, Mike Griffiths just published two useful posts to help us get more out of this critical activity:

• Five things to think about before stand-up
• Five things to think about after stand-up