- Cuando se utiliza TDD en un proyecto virgen, en raras ocasiones se tiene la necesidad de utilizar el depurador o debugger.
- A pesar de los elevados requisitos iniciales de aplicar esta metodología, el desarrollo guiado por pruebas (TDD) puede proporcionar un gran valor añadido en la creación de software, produciendo aplicaciones de más calidad y en menos tiempo.
- Proporciona al programador una gran confianza en el código desarrollado.
- Minimiza el número de bugs en producción.
- El equipo de desarrollo se focaliza en lo que el cliente quiere (todavía mucho más si se aplica ATDD).
Cuesta muchísimo trabajo encontrar en la literatura y en la bibliografía las desventajas del uso de TDD. Aquí pongo un listado de las que he encontrado:
- Aprender bien la técnica es todo un reto.
- Muchos tests pueden ser difíciles de escribir, sobretodo los tests no unitarios.
- Casi imposible de aplicar a código "legacy".
- TDD incrementa enormemente la confianza, pero puede crear una falsa sensación de seguridad.
- Al igual que introducimos bugs al programar el código, es posible introducir bugs al programar los tests.
- Si el programador malinterpreta la especificación entonces se acabará creando un test que llevará a un código que pasa el test pero que está mal.
- Los tests automatizados no son sustitutos de testeadores reales. Siempre es necesaria la mezcla de ambos.
- Dado que los programadores que escriben el código, testean el código, se pierden la buena práctica de que el testeador sea distinto del programador.