En un post reciente, Michael Feathers destaca la idea que el test unitario, por si mismo, no mejora la calidad. Luego de un análisis de los test unitarios, tests de integración y TDD, concluye que la calidad es una forma de pensamiento y reflexión, y no de prevención de bugs. Por otro lado, Steve Freeman nos cuenta, con un enfoque similar, porqué TDD es tan útil.
Michael explica que la idea de mejorar la calidad por el simple hecho de encontrar bugs es errada. Una teoría común sobre el testeo unitario es que la calidad surge de los errores que se van encontrando y arreglando. Superficialmente parece tener sentido. Los tests pueden pasar o fallar, y cuando fallan nos damos cuenta que existe un error para corregir. De ser así, se esperaría encontrar menos errores de integración cuando se realizan las pruebas de integración, y menos errores unitarios cuando se realiza la prueba unitaria. Es una linda teoría, pero está equivocada. La mejor forma de verlo es comparar al testeo unitario como una forma más de mejorar la calidad: una forma que tiene un efecto muy medible.
Para probar su punto, Michael lo compara con una práctica de desarrollo utilizada durante los años '80, llamada Clean Room Software Development ("Desarrollo a Cuarto Limpio"). En Cuarto Limpio, el software no contenía ningún test unitario, sin embargo el código tenía muy buena calidad. La noción detrás de Cuarto Limpio era de incrementar la calidad al incrementar el rigor del desarrollo. En Cuarto Limpio, se debían escribir predicados lógicos para cada porción de código, y se debía demostrar posteriormente durante una revisón que el código escrito hacía exactamente lo que describía el predicado. Cuarto Limpio era sumamente riguroso, y de hecho exigía que no existiera ningún test unitario. Cero. Nada. Cuando se escribia código, el mismo se consideraba correcta una vez revisado. Sólo se realizaban tests a nivel funcional.
Lo más intersante de Cuarto Limpio eran los resultados obtenidos, aumentando la calidad de código sin realizar test unitario. Lo que ocurrió en aquel entonces con Cuarto Limpio es lo que ocurre hoy con TDD: se fuerza al desarrollador a revisar constantemente su código, realizar refactos y mejorar el código. El punto es que no se puede mirar al testo de forma mecánica. El testeo unitario y de integración no mejoran la calidad sólo por atrapar errores en diferentes niveles. La verdad es más sútil: la cálidad es una forma de pensamiento y reflexión; un pensamiento y reflexión muy precisos. Esa es la magia. Todas las técnicas que refuerzan la disciplina invariablemente mejoran la calidad.
En general, las personas no analizan los pros y contras de diferentes soluciones para elegir la mejor opción. En cambio, utilizan el enfoque de "primero que sirve": buscan soluciones a través de una lista de respuestas ya aprendidas, y eligen la primera que parece servir. El cerebro luego se encarga de realizar una justificación para la opción tomada. Y todo esto ocurre en el subconsciente, sin darse cuenta.
La idea es dejar de usar la primer solución que se nos ocurre, y comenzar a evaluar distintas opciones. Por esto es que TDD es tan útil. TDD funciona al romper el método de usar el "primero que sirve". Nos fuerza a estar fuera de nuestra área cómoda el tiempo suficiente como para analizar el requerimiento real que deberíamos solucionar. Mejor aún, comenzar con un test nos obliga a pensar primero en lo que se necesita ("¿para qué es este test?"), y luego en una solución para el problema.
Traducido de la nota Quality is a function of thought and reflection, not bug prevention, de InfoQ.