Este punto de vista es el que defiende Shannon Behrens en una entrada en Dzone. Según él, una de las lecciones que ha aprendido haciendo TDD es que los test no sirven realmente para encontrar bugs; esto es imposible porque la primera vez que estás escribiendo el código tú no sabes cómo ese código se va a usar, y no vas a ser capaz de crear los test adecuados.
Shannon describe su experiencia con TDD: al principio hacía muchos test que él consideraba muy buenos, y al final no tenía tiempo ni energía para hacer mucho QA, pero pensaba que no era necesario por los test. Pero después su jefe encontraba un montón de bugs en el código porque lo usaba de formas que él no había previsto.
Desde el punto de vista de Shannon, para lo que sí que es útil TDD es para evitar regresiones: una vez un bug ha sido identificado, se crea un test que lo replica, y se corrige el bug. Si hay una regresión de funcionalidad y volvemos a crear ese bug, el test nos avisará. Pero para garantizar la calidad del código, él cree que un proceso de QA manual es necesario. Citando a Knuth:
Beware of the above code. I have only tested that it works. I haven't actually tried it.
¿Qué opinais vosotros sobre este punto de vista sobre TDD? ¿Unos buenos tests pueden sustituir o no a un proceso de QA? ¿Valen los test para identificar bugs o sólo para identificar regresiones?