Soy parte de un equipo de desarrolladores que trabaja con muchos otros equipos para mantener y mejorar una aplicación que ha estado en uso durante al menos 15 años. Cuando se construyó y diseñó por primera vez, TDD era inaudito.
La aplicación es bastante estable, y rara vez encontramos un error que detiene la presentación, pero hacemos un promedio de uno o dos errores a la semana que reduce considerablemente la calidad del servicio. Estos errores tardan una eternidad en encontrar y corregir, en gran parte debido a señalar con el dedo, y la única prueba que tenemos es la prueba de interfaz. Debido a que se desperdicia mucho tiempo buscando dónde está el error antes de que pueda solucionarse, yo y otro desarrollador planeamos proponer el desarrollo impulsado por pruebas. Pronto habrá una nueva revisión, y nos gustaría ver pruebas de unidades casi completas en los nuevos módulos, también planeamos sugerir la creación de unidades de prueba para cualquier código que tengamos que modificar que sea heredado (es decir, corrección de errores o implementación de características ), pero no para perder tiempo desarrollando casos de prueba para código que no haya causado problemas.
Para mí, esto parece razonable. Este mes tuvimos un error que tardó más de dos semanas en solucionarse, pero podría haberse identificado antes de implementarse si se hubieran realizado pruebas unitarias. Pero para nuestros gerentes parece que van a gastar más dinero.
¿Cómo puedo convencer a nuestros clientes de que quieren gastar el dinero en pruebas unitarias y desarrollo basado en pruebas? ¿Hay algún estudio que muestre el ROI de las pruebas unitarias?
fuente
Respuestas:
Incorporación directa de TDD completo en un código heredado, el proyecto de mantenimiento es muy difícil de vender. Un enfoque que he visto funcionar muy bien es este. Para cada error que entre, cree una prueba automatizada sin unidad que demuestre el error. Por "no unidad", me refiero a algo que puede tocar muchas partes del sistema, golpear la base de datos y el sistema de archivos, etc., pero por "automatizado" me refiero a ejecuciones sin interacción humana. Este es el tipo de prueba que deseará en su conjunto de regresión en cualquier caso. Escribirlo logra muchas cosas: hace que el código sea comprobable, incluso en ese nivel muy burdo, y lo expone a la constelación de código que podría tener algo que ver con el error, por lo que lo educa e informa sobre material muy específicamente relevante.
Pero ese no es el final. Una vez que esta prueba se está ejecutando y se está ejecutando en rojo (lo que demuestra el error en el código), tómese el tiempo para descubrir qué está mal (debe hacer esto, en cualquier caso). Pero no lo arregles todavía. Una vez que haya aislado lo que cree que es el problema, escriba una unidadprueba que demuestra ese problema. Ahora tiene algo con lo que puede trabajar (y, por cierto, es posible que haya tenido que refactorizar un poco más para lograr una mayor capacidad de prueba). Arregla el error. Observe el pase de prueba de la unidad. Tal vez desarrollarlo con algunos casos de borde; obtenga esa unidad, la que le costó dos semanas de tiempo, sólida, limpia y bien probada. Ahora ejecute la prueba de regresión y obsérvela pasar (por supuesto, si no es así, tiene más investigación y trabajo a nivel de unidad que hacer, repita hasta que también pase). Compruébalo todo. ¿Qué tienes? Pruebas de regresión para el código que anteriormente fallaba. Pruebas unitarias para el código que falla previamente. Código de trabajo que estaba fallando. Código mejor diseñado, porque ahora es más comprobable de lo que era. Mayor confianza en su código base,
No es TDD "puro". Pero demuestra resultados, rápidamente, y mejora la calidad de su código con el tiempo. Los resultados lo ayudarán a obtener la aceptación de la administración.
fuente
En mi empresa, simplemente utilicé el método "solo un gruñido" de JoelOnSoftware y comencé a escribir pruebas unitarias siempre que normalmente simplemente hubiera pirateado algún tipo de aplicación de consola desechable. Comencé a hacer las cosas mucho más rápido con lanzamientos más estables, y me di cuenta por ello. Cuando me preguntaron qué estaba haciendo, le expliqué que había comenzado a usar TDD y escribir pruebas unitarias cada vez que modificaba el código antiguo o escribía cualquier código nuevo. Mis colegas desarrolladores comenzaron a sentir curiosidad y comenzaron a usar pruebas unitarias integradas. No creo que haya un buen argumento para escribir pruebas para el código heredado de trabajo, pero si puede argumentar que escribir pruebas automatizadas es más rápido y más conveniente que escribir espaguetis de corte de consola, entonces los desarrolladores inteligentes seguirán.Los otros beneficios que dan como resultado un software de mayor calidad también estarán allí, pero la clave para obtener el inicio de sesión del desarrollador es demostrar que les facilita la vida. En cuanto a que las empresas inicien sesión, el hecho de que dará como resultado un mejor software y probablemente tomará menos tiempo para enviar que antes debería ser más que suficiente para convencerlos.
fuente
En primer lugar, su actitud y sentido de sinceridad por el valor de calidad se suman al dinero del cliente. Y aquí están mis pensamientos sobre cómo puede convencer a su gerente y cliente:
Hay otra forma, y es tratar de unirse a su gerente para asistir a las conferencias ágiles que suceden. Ciertamente debería valer la pena asistir.
Si crees que nada funciona, sigue adelante ... únete al lugar que más te convenga. Sinceramente, esto es lo que hice. Cuando todo falló, seguí adelante;)
Y sepa qué pruebas de Unit después de escribir el código no es realmente TDD, pero ese siempre puede ser el primer paso. Encaja muy bien aquí al menos.
¡Te deseo buena suerte y éxito!
fuente