Desarrollo impulsado por pruebas: ¡convencerme! [cerrado]

Sé que algunas personas son defensores masivos del desarrollo basado en pruebas. He usado pruebas unitarias en el pasado, pero solo para probar operaciones que pueden probarse fácilmente o que creo que posiblemente sean correctas. La cobertura de código completa o casi completa parece que llevaría mucho tiempo.

1. ¿Para qué proyectos utiliza el desarrollo basado en pruebas? ¿Solo lo usas para proyectos por encima de cierto tamaño?
2. ¿Debería usarlo o no? ¡Convenceme!

Ok, algunas ventajas de TDD:

1. Significa que terminas con más pruebas. A todos les gusta hacerse exámenes, pero a pocas personas les gusta escribirlos . Incorporar la escritura de prueba en su flujo de desarrollo significa que terminará con más pruebas.
2. Escribir en una prueba lo obliga a pensar en la capacidad de prueba de su diseño, y el diseño comprobable es casi siempre un mejor diseño. No está del todo claro para mí por qué es así, pero mi experiencia y la de la mayoría de los evangelistas de TDD parece confirmarlo.
3. Aquí hay un estudio que dice que aunque TDD tarda un poco más en escribir, hay un buen retorno de la inversión porque obtienes un código de mayor calidad y, por lo tanto, menos errores para corregir.
4. Le da confianza en la refactorización. Es una gran sensación poder cambiar un sistema sin preocuparse por romper todo lo demás porque está bastante bien cubierto por las pruebas unitarias.
5. Casi nunca se repite un error, ya que cada uno que encuentre debe hacerse una prueba antes de que se solucione.

Pediste ser convencido, así que estos fueron beneficios. Vea esta pregunta para una visión más equilibrada.

Robert C. Martin originalmente hizo estos puntos: puedo respaldarlos desde mi propia experiencia:

• Creará automáticamente un conjunto de pruebas de regresión de pruebas unitarias a medida que avanza.
• Casi nunca pasará tiempo depurando, ya que si se codifica en un agujero, es más fácil deshacer su código hasta el punto en que pasó la última prueba, en lugar de abrir un depurador.
• Cada pocos minutos verifica que su código funciona, todo (o al menos todo el comportamiento cubierto por las pruebas, que si está haciendo TDD es un porcentaje muy alto).

Prácticamente hago TDD todo el tiempo, ya sea que esté trabajando en producción o reproduciendo código; Me resulta difícil codificar de otra manera en estos días.

(Descargo de responsabilidad: no hago casi nada de IU, por lo que no puedo hablar de TDD para IU)

Uso TDD en casi todo lo que hago, desde aplicaciones triviales hasta pilas SIP completas.

No uso TDD en un sitio PHP heredado que asumí. Me resulta doloroso no tener pruebas. Y me resulta muy molesto romper accidentalmente partes del sitio porque no tengo un conjunto de pruebas de regresión que me diga que rompí algo. El cliente no tiene el presupuesto para que yo (a) escriba pruebas para la base de código y (b) en el proceso haga que el código sea comprobable en primer lugar, así que simplemente lo aguanté.

• Siempre que su cliente pueda ser suministrado de manera más efectiva (posiblemente se relacionen bien con las pruebas, y al menos reducirá la discusión al final del proyecto)
• Siempre que lleve más tiempo, mantenga informados a sus codesarrolladores sobre TODO EL código que haga un esfuerzo para construir la prueba, y esto es antes de lo que pueda pensar.

¿Qué? ¿No hay respuesta negativa?

Descargo de responsabilidad: no estoy realizando pruebas antiunitarias. Cuando la gente dice TDD, supongo que se refieren a la versión que suena a enfermedad en la que escriben pruebas antes de escribir el código del 80-100% de todo el código que escriben.

Yo argumentaría:

• Es un facilitador. Si la captura de problemas de regresión es un problema tan grande para usted que TDD totalmente automático desde el principio parece valioso, escribir pruebas para cada último fragmento de código que escriba, en realidad podría ayudarlo a ignorar el problema real.

• Ayuda a las personas a ignorar el verdadero problema. Cuando la reparación de un error se convierte en un juego de whack-a-mole donde aparecen dos ventanas emergentes más, la arquitectura explota. Atención. Centrarse en el verdadero problema. Ver los lunares antes de que sean golpeados es genial, pero no deberías estar allí en primer lugar.

• Se come mucho tiempo. Golpeé errores ocasionales. No alcanzo tantos que parece que vale la pena prefijar cada cosa nueva que escribo con una prueba. Detecte problemas donde es probable que sucedan. Maneje los errores de manera que sean fáciles de diagnosticar. Validar. Pruebe en puntos clave de superposición / cuello de botella. Pero por el amor de Dios, no pruebes hasta el último getter y setter en algo que probablemente no debería haber tenido en primer lugar.

• Enfoque de diseño: no hay absolutamente ninguna manera de que incluso un buen desarrollador escriba el mejor código que pueda cuando también se está centrando en la prueba. Si parece ser la única forma de tener un diseño decente, recomendaría ver lo anterior sobre "centrarse en el problema real".

• Error de diseño macro: la base de código en mi trabajo actual está plagada de interfaces que nunca se usan más de una vez y violaciones masivas del principio DRY básico que solo finalmente comencé a entender cuando me di cuenta de que las personas escribían para los marcos de prueba y las pruebas en general. Las pruebas no deberían conducir a una arquitectura estúpida. No, en realidad, no hay nada que sea de alguna manera más escalable o digno de la empresa para copiar y pegar 20 archivos y luego solo hacer cambios significativos en dos de ellos. La idea es separar las preocupaciones, no dividirlas por la mitad. La abstracción cruda e inútil le costará más de lo que nunca tendrá una cobertura del 95%.

• Es muy popular y a mucha gente le gusta mucho. Si esa no es razón suficiente para al menos dudar y / o investigar cualquier tecnología antes de la adopción, aprende algo de paranoia.