¿Cuál es el mejor argumento para convencer a los desarrolladores para que aprendan TDD?

Question

Permítanme salir del armario. Soy un creyente TDD. Intento practicar el desarrollo impulsado por pruebas tanto como pueda.

Algunos desarrolladores en mi trabajo se niegan incluso a intentarlo. Yo mismo comencé a TDD tratando de demostrarle a uno de mis compañeros que Test Driven Development es una mala idea. Los argumentos son:

• ¿Por qué? Fui desarrollador bastante exitoso hasta ahora.
• Me va a retrasar.

¿Cuál es el mejor argumento pro TDD que oí o usé?

---

Consulte también:What is the best reason for unit testing?

Answer 1

TDD es una compensación "pagueme ahora o pague después". Si solo cuenta el tiempo desde el inicio de la codificación hasta el registro de su código, TDD generalmente toma más tiempo, especialmente cuando primero aprende TDD. El pago viene más tarde durante la fase de prueba, y también en futuras rondas de codificación.

Para la fase de pruebas, descubrí que con TDD:

1. que tenía substancialmente menos errores. Mi último código TDD tuve errores solo debido a malentendidos (o cambios) de los requisitos o en las áreas donde no pude poner el código bajo prueba (código PHP en ese caso).
2. Los errores que tenía eran generalmente más fáciles de reproducir bajo prueba, porque ya había probado el sistema.
3. La solución de los errores fue más rápida, y con las pruebas podría tener una mayor creencia de que no introduje nuevos errores.

El código en sí tenía las siguientes propiedades:

1. Como empecé a pensar como un cliente del código, el código tendían a ser más fácil de usar. (Este es uno de los beneficios de escribir pruebas primero).

2. El código es más fácil de probar.

3. Escribir pruebas de unidad es más fácil (y en muchos casos más divertido) justo antes que después, por lo que se escriben más pruebas.

4. El código es más fácil de refactorizar y limpiar. Esto fue particularmente cierto con Python, donde las herramientas de refactorización automáticas tienen más dificultades.

Debido a eso, cuando llegó el momento de volver a examinar el código, era más fácil de entender y fácil de cambiar, y además teníamos al menos algunas pruebas de regresión ya en su lugar.

Lo que esto significa es que la amortización del tiempo TDD puede ser meses posterior. Además, iniciar TDD con código heredado es particularmente difícil. Luego, se necesita tiempo para aprender a escribir buenas pruebas (un conjunto de pruebas incorrecto puede ser insuficiente o peor, ser frágil y dificultar, no hacer las refactorizaciones) y cómo probar un sistema complejo.

Tengo que admitir que no he sido capaz de conseguir que muchas otras personas cambien a TDD.Creo que cambié en gran medida porque quería una forma más sencilla de prueba y también tuve la oportunidad de aprender cómo con una pequeña base de código y un proyecto personal.

Answer 2

Los argumentos que se enumeran no son argumentos racionales y lógicos. No tienen razonamiento detrás de ellos (a menos que usted haya resumido argumentos reales mucho más largos)

Como tal, no creo que pueda convencer a nadie que haga esas afirmaciones con argumentos racionales propios . La mejor manera será apelar a la fuente de sus argumentos; experiencia. O haz que usen TDD por un tiempo de manera provisional para ver qué piensan de él, o si no, hazlo tú mismo, que es claramente un trabajo muy bueno, y preséntalo como un ejemplo para ellos.

(no soy un creyente TDD. Esta es una manera práctica que podría convencerme de que era una buena idea.)

Answer 3

Ninguna cantidad de argumento será convencer a nadie a utilizar TDD.

Tienes que MOSTRARlas y demostrar los beneficios. Es más fácil hacer que la luz de alguien se encienda mostrando más que diciendo.

Answer 4

Como desarrollador profesional durante más de 10 años, el mejor argumento que puedo presentar es que incluso encontré mis errores antes de llegar a un punto de poder "ejecutar" la aplicación.

También encontré que el diseño de mi código era más robusto y fácil de cambiar, y me dio más confianza para refactorizar.

"Bastante exitoso" no es igual a "Muy exitoso".

La otra gran ventaja es que ya no tengo que escribir arneses de prueba ya que los correctores de pruebas unitarias se convierten en mi arnés de prueba.

Answer 5

Muéstreles esta presentación. Me vendió.

http://www.slideshare.net/sebastian_bergmann/testing-with-phpunit-and-selenium-156187

Cualquier programador que jamás se ha enfrentado a una tarea muy compleja con una gran cantidad de condiciones de borde debe ser capaz de ver el valor de TDD. Cuando se trata de algo así como asegurarse de que un motor de búsqueda coincida con ciertas cadenas, TDD es la única forma en que podrá mantenerse sano durante el mantenimiento: la única manera de asegurarse de haber solucionado un caso sin afectar a otros. es con pruebas automatizadas.

Answer 6

Diferentes personas estarán convencidas (o no) de diferentes maneras, por lo que la única respuesta honesta es "depende".

Una de las formas en que he visto trabajar varias veces es sentarte con alguien después de que han estado luchando con un trozo de código, y recrearlo usando TDD. El código resultante suele ser más pequeño y más claro.

Answer 7

No practico TDD. Aunque veo que es bueno si tiene proyectos complejos en los que tiene muchos casos de prueba diferentes para probar, no veo un gran beneficio al usarlo, por ejemplo, en una aplicación web simple.

Una forma en que alguien podría convencerme de usar TDD sería si tomamos el mismo proyecto y lo hicimos uno al lado del otro, vea quién ofrece mejores resultados y quién completa la tarea más rápido.

Answer 8

Quizás ellos sepan mejor.

Prueba de la unidad por los desarrolladores es una práctica extremadamente útil y no se puede exagerar sus beneficios, no sólo durante el desarrollo inicial, sino también durante la refactorización cuando las pruebas unitarias pueden coger temprano no sólo defectos de código ordinaria, sino también a la ruptura de las suposiciones hechas por desarrolladores que nunca fueron capturados en la documentación formal y, por lo tanto, es probable que se pierdan cuando se produce la refactorización.

Dicho esto, TDD no es polvo de hadas mágico:

1. la 'acaba de escribir código suficiente para pasar la prueba' enfoque da falsos positivos. A menudo se conocen falacias y problemas que el enfoque "lo suficiente" no aborda. Los ejemplos rápidos que se me ocurren son distributed systems fallacies o problemas de rendimiento NUMA. Simplemente capturando esos requisitos en simplemente expresando esos casos de prueba para TDD se convertirían en un trabajo de tiempo completo en sí mismo.
2. la explosión de moqs se sale de control para cualquier proyecto de tamaño serio. los simulacros son como cualquier otro código, deben mantenerse y simplemente no se escriben de la nada.
3. TDD se usa a menudo como una excusa para eliminar las pruebas de control de calidad. 'nuestro desarrollador ya ha escrito la identificación de prueba, vamos a enviarlo' descuida por completo las pruebas orientadas a funciones de extremo a extremo QA debe cubrir
4. No confío en el zorro que vigila la gallinero. Un algoritmo erróneo aún puede pasar el TDD con gran éxito si se cometen los mismos errores tanto en la prueba como en la implementación.
5. Todas las metodologías al final intentan utilizar el proceso para sustituir el talento.

Mi pelea principal con TDD es que se presenta como una solución mágica para la mayoría de los problemas de desarrollo, pero su costo se mantiene debajo de la mesa por sus defensores. Duplicar o triplicar su base de código con moqs no es gratis. Prefiero ver algunas pruebas integrales de unidades escritas durante el desarrollo. El enfoque TDD de prueba primero, todavía no veo sus beneficios en un proyecto de tamaño real.

entiendo que estaré huevo de opinión a la muerte ahora para publicar esto, pero por qué no, a quién le importa ...

Answer 9

par con ellos. No tiene que llamarlo "programación de pares", es aterrador para alguien que es reacio incluso a considerar técnicas "radicales" como TDD, pero si los dos se sientan en un escritorio y trabajan juntos en el mismo problema, es fácil demostrar el valor de TDD. Ese no puede ser el final de la conversación, pero es un gran comienzo. Le da credibilidad para el resto de la conversación y le brinda algo real como base para una discusión posterior.

Answer 10

Las pruebas exhaustivas de la unidad reducen las ocurrencias de errores, pero también reducen la recidiva o el alcance del daño causado por la recidiva.

Answer 11

El momento "aha" para mí fue leer el capítulo 2 de "Test-Driven Development en Microsoft.Net" por James Newkirk. (No es que el resto del libro no fuera importante ... dedica varios capítulos a crear una aplicación de varios niveles en TDD).

Construye una pila simple, pero se ve que el código "evoluciona" su complejidad en lugar de comenzar complejo.

Incluso entonces, todavía tendrá problemas para convencer a los que no lo hacen porque parece que TDD requiere mucho más trabajo que la programación tradicional. La mayoría de los desarrolladores anti-TDD, sin embargo, se olvidan de tener en cuenta el tiempo de desarrollo para las pruebas unitarias al final, al menos en mi experiencia.