tipos - ¿Cuáles son algunos malentendidos comunes sobre TDD?

tdd vs bdd (6)

Leyendo las respuestas a esta pregunta ¿ Desventajas del desarrollo impulsado por prueba? Tengo la impresión de que hay muchos malentendidos sobre lo que es TDD y cómo se debe llevar a cabo. Puede ser útil abordar estos problemas aquí.

En mi humilde opinión, la mayor idea errónea sobre TDD es que: el tiempo dedicado a escribir y refactorizar las pruebas sería tiempo perdido. El pensamiento es como "sí, un banco de pruebas es bueno, pero la función estaría completa mucho más rápido si solo la codificamos".

Cuando se hace correctamente, el tiempo dedicado a escribir y mantener las pruebas se guarda varias veces durante la vida del proyecto, en el tiempo que no se gasta en la depuración y en la fijación de regresiones. Dado que el costo de la prueba es inicial y la recompensa es a través del tiempo, es fácil pasar por alto.

Otros grandes conceptos erróneos incluyen ignorar el impacto de TDD en el proceso de diseño, y no darse cuenta de que "pruebas dolorosas" es un olor a código serio que debe corregirse rápidamente.

Estos son los problemas que, en mi opinión, son bastante controvertidos y, por lo tanto, propensos a malentendidos:

En mi experiencia, la mayor ventaja es producir código mucho mejor a costa de mucho tiempo dedicado a escribir pruebas. Entonces, realmente vale la pena para proyectos que requieren alta calidad, pero en algunos otros sitios céntricos de menor calidad, el tiempo extra no valdrá la pena.
La gente parece pensar que solo un subconjunto importante de las características debe ser probado, pero eso es realmente incorrecto en mi humilde opinión. Debe probar todo para que su prueba sea válida después de la refactorización.
El gran inconveniente de TDD es la falsa sensación de seguridad que ofrecen las pruebas incompletas: he visto que los sitios se caducan porque la gente suponía que la Prueba Unitaria era suficiente para activar una implementación.
No hay necesidad de burlarse de los marcos para hacer TDD. Es solo una herramienta para probar algunos casos de una manera más fácil. Sin embargo, las mejores pruebas unitarias se disparan a gran altura en la pila y deben ser independientes de las capas del código. Probar una capa a la vez no tiene sentido en este contexto.

La idea errónea que a menudo veo es que TDD asegura buenos resultados.

A menudo, las pruebas se borran de los requisitos defectuosos, y por lo tanto, los desarrolladores producen un producto que no hace lo que el usuario está esperando. La clave para TDD es, en mi opinión, trabajar con los usuarios para definir los requisitos y ayudar a administrar sus expectativas.

Veo a mucha gente malentendiendo qué pruebas realmente son útiles para TDD. Las personas escriben grandes pruebas de aceptación en lugar de pruebas de unidades pequeñas y luego pasan demasiado tiempo manteniendo sus pruebas y luego concluyen que el TDD no funciona. Creo que la gente de BDD tiene un punto para evitar el uso de la palabra prueba por completo.

El otro extremo es que las personas dejan de hacer las pruebas de aceptación y piensan que, debido a que hacen pruebas unitarias, su código es probado. Esto es una vez más un malentendido de la función de una prueba unitaria. Aún necesitas pruebas de aceptación de algún tipo.

Solo lanzando otra respuesta en el bote.

Uno de los malentendidos más comunes es que su código es fijo , es decir. Tengo este código, ¿cómo lo voy a probar? Si es difícil escribir una prueba, deberíamos hacernos la pregunta: ¿cómo puedo cambiar este código para que sea más fácil de evaluar?

Por qué..?

Bueno, el tipo de código que es fácil de probar es:

Modular: cada método hace una cosa.
Parametrizado: cada método acepta todo lo que necesita y genera todo lo que debería.
Bien especificado: cada método hace exactamente lo que debería, ni más ni menos.

Si escribimos código como este, la prueba es un doddle. Lo interesante es que el código que es fácil de probar es, casualmente, un mejor código .

Mejor que sea más fácil de leer , más fácil de probar , más fácil de entender , más fácil de depurar . Esta es la razón por la que TDD a menudo se describe como un ejercicio de diseño.

Siento que la respuesta aceptada fue una de las más débiles (¿ Desventajas del desarrollo impulsado por prueba? ), Y la respuesta más modificada huele a alguien que podría estar escribiendo pruebas específicas.

Gran inversión de tiempo: para el caso simple, se pierde alrededor del 20% de la implementación real, pero en casos complicados se pierde mucho más.

TDD es una inversión. Descubrí que una vez que estaba totalmente inmerso en TDD, el tiempo que perdí es muy, muy poco, y el tiempo que perdí fue más que compensado en lo que respecta al tiempo de mantenimiento.

Para casos complejos, los casos de prueba son más difíciles de calcular. En casos como este, sugiero que se intente utilizar un código de referencia automático que se ejecutará en paralelo en la versión de depuración / prueba, en lugar de la prueba unitaria de los casos más simples.

Si su prueba se está volviendo muy compleja, podría ser el momento de revisar su diseño. TDD debería guiarlo por el camino unidades de código más pequeñas y menos complejas trabajando juntas

Algunas veces, el diseño no está claro al principio y evoluciona a medida que avanzas; esto te obligará a volver a realizar la prueba, lo que generará un gran momento de pérdida. Sugeriría posponer las pruebas unitarias en este caso hasta que tenga un poco de conocimiento del diseño en mente.

¡Este es el peor punto de todos! TDD realmente debería ser un " Diseño impulsado por prueba". TDD se trata de diseño, no de prueba. Para darse cuenta completamente del valor de los beneficios de TDD, usted tiene un diseño de juguete de sus pruebas. Así que deberías rehacer tu código de producción para que tus pruebas pasen, no al revés, como sugiere este punto

Ahora el más actual upmodded: Desventajas del desarrollo impulsado por prueba?

Cuando llega al punto en que tiene una gran cantidad de pruebas, cambiar el sistema puede requerir volver a escribir algunas o todas sus pruebas, dependiendo de cuáles hayan sido invalidadas por los cambios. Esto podría convertir una modificación relativamente rápida en una muy lenta.

Al igual que el primer punto de las respuestas aceptadas, esto parece más que una especificación en las pruebas y una falta general de comprensión del proceso TDD. Al hacer cambios, comience desde su prueba. Cambie la prueba de lo que debería hacer el nuevo código y realice el cambio. Si ese cambio rompe otras pruebas, entonces tus pruebas están haciendo lo que se supone que deben hacer, fallando. Las pruebas unitarias, para mí, están diseñadas para fallar, por lo tanto, la etapa ROJA es lo primero y nunca se debe perder.