¿Hay áreas donde TDD proporciona un ROI alto y otras áreas donde el ROI es tan bajo que no vale la pena seguirlo? [cerrado]

Prueba de desarrollo impulsado. Lo entiendo, me gusta.

Pero escribir pruebas requiere gastos generales. Entonces, ¿debería TDD usarse universalmente en toda la base del código, o hay áreas donde TDD proporciona un ROI alto y otras áreas donde el ROI es tan bajo que no vale la pena seguirlo?

Yo diría que evite TDD en lugares donde es probable que el código cambie estructuralmente mucho. Es decir, es genial tener un montón de pruebas para un método cuya firma cambia raramente pero se refactoriza internamente con más frecuencia, pero es una molestia tener que arreglar sus pruebas cada vez que una interfaz altamente volátil cambia drásticamente.

Las aplicaciones en las que he estado trabajando recientemente han sido aplicaciones web basadas en datos basadas en una arquitectura Gui-> Presenter-> BusinessLogic-> Data Access Layer. Mi capa de acceso a datos se prueba como si fuera asunto de nadie. La capa de lógica de negocios está bastante bien probada. Los presentadores solo se prueban en las áreas más estables, y la GUI, que cambia cada hora, casi no tiene pruebas.

Sugiero escribir un conjunto completo de pruebas en áreas donde es sensato y práctico hacerlo. En áreas menos prácticas, escriba controles de cordura.

En mi experiencia, la sobrecarga de un conjunto completo de casos de prueba ciertamente vale la pena en la mayoría de los casos, pero de manera realista la cobertura del código tiene rendimientos decrecientes. En algún momento, escribir más pruebas solo para aumentar la cobertura del código simplemente no tiene sentido.

Por ejemplo, dependiendo de su idioma / tecnología, probar la interfaz de usuario puede no ser práctico o incluso factible. Muchas pruebas probablemente dependerán de lo que un usuario ve y no puede automatizarse. ¿Cómo probarías que un método para generar un captcha produce una imagen legible por un humano, por ejemplo?

Si un conjunto completo de pruebas le tomará tres días para escribir, la probabilidad de que se introduzca un error en ese componente en la pista es muy baja, y la función en sí solo toma media hora para escribir, probablemente debería pensar mucho sobre si ese tiempo vale la pena. ¿Quizás solo escribir un chequeo de cordura básico para esa función proporcionaría valor?

Mi consejo general sería que debe probar los componentes por completo donde las pruebas se pueden escribir con relativa facilidad. Sin embargo, si es un área que es muy difícil de probar, dibuje una línea en la arena y escriba pruebas que evalúen el área a un nivel más alto en lugar de probarla completamente.

En el ejemplo anterior de captcha, quizás escriba pruebas que verifiquen que se devuelve una imagen del tamaño y formato correctos y que no se arrojen excepciones. Eso le da cierto nivel de seguridad sin exagerar.

Para mí, TDD no está sobrecargado. Es solo la forma en que escribo el código. ¿Por qué dices que la prueba de escritura está "sobrecargada"? Es solo parte del proceso. Mi punto de vista es que la depuración está sobrecargada, y esa es una actividad que esencialmente dejé de hacer cuando comencé a TDD. Antes de TDD, la depuración era una parte integral de mi proceso de escritura de software.

Creo que renunciar a la depuración para la redacción de pruebas es una muy buena oferta.

Un lugar donde TDD realmente apesta es cuando se prueban vistas en una aplicación MVC.

Como está probando una función que devuelve una cadena html gruesa, está atascado haciendo un análisis html solo para ver si las cosas funcionaron. Además, puede convertirse en una pesadilla de mantenimiento. Un día mueves una casilla de verificación y kaboom, tu prueba está rota.

Me gusta TDD para muchas de mis pruebas, pero no es la única herramienta en un cinturón de programadores.