it-swarm-es.com

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

Desarrollo impulsado por pruebas. Lo entiendo, me gusta.

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

32
Phillip Ngan

Yo diría que evite TDD en lugares donde es probable que el código cambie mucho estructuralmente. 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 apesta tener que corregir tus pruebas cada vez que una interfaz altamente volátil cambia dramáticamente.

Las aplicaciones en las que he estado trabajando recientemente han sido aplicaciones web basadas en datos creadas en una arquitectura basada en Gui-> Presenter-> BusinessLogic-> Data Access Layer. Mi capa de acceso a datos se prueba como nadie. La capa de lógica empresarial 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.

27
Fishtoaster

Sugiero escribir un conjunto de pruebas completo en áreas donde sea 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 la cobertura de código de manera realista 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 ve un usuario y no se pueden automatizar. ¿Cómo probaría que un método para generar un captcha produce una imagen que un humano puede leer, por ejemplo?

Si un conjunto completo de pruebas le llevará tres días escribirlo, la probabilidad de que se introduzca un error en ese componente en el futuro 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 una verificación de cordura básica para esa función proporcionaría valor?

Mi consejo general sería que debería probar los componentes por completo donde las pruebas se puedan 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 probarán el área a un nivel más alto en lugar de probarla completamente.

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

7
Damovisa

Para mí, TDD no es un gasto indirecto. Es simplemente la forma en que escribo el código. ¿Por qué dices que la prueba de escritura es "indirecta"? Es solo parte del proceso. Mi punto de vista es que depuración es una sobrecarga, y esa es una actividad que básicamente dejé de hacer cuando comencé a TDD-ing. Antes de TDD, la depuración era una parte integral de mi proceso de escritura de software.

Creo que renunciar a la depuración por la escritura de pruebas es una muy buena ganga.

6
xpmatteo

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

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

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

3
Sam Saffron