Unit Testing
This statement from http://www.joelonsoftware.com/items/2004/12/06.html irritated me:
However, a good, experienced developer is about 100 times less likely to write bugs that will be uncovered during unit
tests than a beginner. It is therefore practically useless for the former to write these... but most methodologies would
enforce that he has to, or else you don't pass some phase.
Unit tests serve to measure compliance of code with the developers understanding of the requirements and crucially, control project velocity. If defects from unit tests rise then dev time is spent fixing the code, slowing dev down to a pace where an appropriate degree of compliance is achieved.
If you are very experienced and write largely defect free code you may travel fast and light - turning the unit testing dial down to 3 - maybe only testing the really hard stuff. If you are less experienced or generate defects then you may want to turn that dial up to 7. The problem occurs when you cannot guarantee that the code written will always be updated by the same person, or a person with the same defect introduction profile[1]. In this case you may end up with the dial at the wrong setting, defects are introduced and worse, development isn't slowed to a point where the defects stop appearing in the main code base. Of course, you may have tactical additions that don't have the same quality bar as the rest of the code and you maybe able to turn the dial right down, but that's different as a quality bar applies across the team and not to individuals.
So, change the unit test dial for an individual at your peril, you never know when someone else may edit the code.
A wider problem with the statement is that it shows an atomistic approach whereas IT projects and development teams are complex systems and issues relating to those projects and teams need to be considered holistically as well.
[1] Since turning down the dial has to recognise the types of defects you are going to stop testing for.
However, a good, experienced developer is about 100 times less likely to write bugs that will be uncovered during unit
tests than a beginner. It is therefore practically useless for the former to write these... but most methodologies would
enforce that he has to, or else you don't pass some phase.
Unit tests serve to measure compliance of code with the developers understanding of the requirements and crucially, control project velocity. If defects from unit tests rise then dev time is spent fixing the code, slowing dev down to a pace where an appropriate degree of compliance is achieved.
If you are very experienced and write largely defect free code you may travel fast and light - turning the unit testing dial down to 3 - maybe only testing the really hard stuff. If you are less experienced or generate defects then you may want to turn that dial up to 7. The problem occurs when you cannot guarantee that the code written will always be updated by the same person, or a person with the same defect introduction profile[1]. In this case you may end up with the dial at the wrong setting, defects are introduced and worse, development isn't slowed to a point where the defects stop appearing in the main code base. Of course, you may have tactical additions that don't have the same quality bar as the rest of the code and you maybe able to turn the dial right down, but that's different as a quality bar applies across the team and not to individuals.
So, change the unit test dial for an individual at your peril, you never know when someone else may edit the code.
A wider problem with the statement is that it shows an atomistic approach whereas IT projects and development teams are complex systems and issues relating to those projects and teams need to be considered holistically as well.
[1] Since turning down the dial has to recognise the types of defects you are going to stop testing for.
posted by Andy S at 11:17 AM
<< Home