Muy a menudo, los beneficios del uso de TDD se consideran ganancias 'a largo plazo': el código general estará mejor estructurado, será más verificable, en general menos errores reportados por los clientes, etc.
Sin embargo, ¿dónde están los beneficios a corto plazo del uso de TDD? ¿Hay alguna que sea realmente tengible y fácilmente medible?
¿Es importante tener un beneficio obvio (o incluso no obvio por cuantificable) a corto plazo, si las ganancias a largo plazo son medibles?
Respuestas:
Hay algunos beneficios a corto plazo para TDD, algunos más medibles que otros. Aquí hay algunos de la parte superior de mi cabeza:
Código limpio, siguiendo los buenos principios de SOLID . Es decir, si mantiene sus pruebas tan limpias como su código y evita el código de prueba híbrido sucio , el código tenderá a seguir SOLIDO. El código limpio es más fácil de leer y es más fácil mantener su código desde el principio. Las horas de trabajo se ahorran durante el mantenimiento, pero a corto plazo: obtendrá un código más limpio más rápido (porque tiene algunas pruebas que lo respaldan).
Pruebas de regresión desde el inicio; lo rompiste se le conoce al respecto ... temprana. Respaldado por un servidor de CI, esto le ahorrará un poco de pelo. Las horas hombre para arreglar un error regresivo que descubrirá temprano sin pruebas son difíciles de medir, pero digamos que son muchas horas hombre.
Permite refactorizar sin demasiadas conjeturas. Si tiene un conjunto de pruebas para una clase, será fácil refactorizarlo (como extraer métodos, usar otras estructuras de datos, extraer clases) porque ha definido las pruebas desde el principio. Lo que llevaría días refactorizar una clase tomará menos de una; y puede hacerlo de inmediato si tiene las pruebas realizadas anteriormente.
El diseño basado en pruebas le permite corregir la duplicación de código temprano. Al menos si eres un programador observador; porque probar con código duplicado (tanto en código de prueba como en código de producción) se convierte rápidamente en una tarea aburrida. Cuanto más inteligente sea con su código de prueba, mejor será. Menos código, menos molestias, más horas hombre ahorradas.
EDITAR También agregado por Frank Shearar, que estoy de acuerdo:
En cualquier momento tiene un código de trabajo (excepto el caso de prueba con el que está trabajando actualmente).
Encontrar errores o problemas de diseño temprano a través de TDD es realmente invaluable y es difícil medir cuánto ahorra en horas hombre; aunque una forma sería contar las horas que ha dedicado anteriormente a trabajar en problemas de diseño al final del desarrollo. Con las pruebas unitarias, se puede ejercer un subconjunto de su código a través de sus pruebas sin tener que ejecutar su aplicación o sistema real. De esa manera, puede asegurarse a través de TDD de que alguna parte de su programa está funcionando en este momento , a pesar de que en este momento no esté conectado a la realidad.
Por corto plazo, ¿te refieres a pequeños proyectos, o te refieres a los primeros días de un proyecto?
Soy de la opinión de que integrar las pruebas mientras se establecen los primeros cimientos pagará dividendos de inmediato porque ha verificado los pilares sobre los que se sostendrá todo el resto del proyecto. Tiendo a diseñar de arriba hacia abajo e implementar de abajo hacia arriba, así que esto tiene sentido para mi forma de trabajar.
Si ahora se da cuenta de una inconsistencia ahora, su trabajo se ha pagado solo al no tener que depurar un programa más complejo más adelante.
Además, su proyecto ya está configurado para pruebas y no tendrá que refactorizar una plataforma más adelante.
Un beneficio a muy corto plazo que encuentro con TDD es que no tengo que concentrarme tanto en lo que estoy tratando de lograr.
Si me interrumpen de mi trabajo, sin TDD, me llevará unos minutos recordarme dónde estoy cuando vuelva a la tarea.
Con TDD acabo de ejecutar las pruebas, veo cuál falla e instantáneamente sé lo que estaba tratando de lograr. Trabajo más rápido con menos dolor cerebral.