Leyendo las respuestas a esta pregunta Disadvantages of Test Driven Development? Me dio la impresión de que hay muchos malentendidos sobre qué es TDD y cómo se debe llevar a cabo. Puede ser útil abordar estos problemas aquí.¿Cuáles son algunos malentendidos comunes sobre TDD?
Creo que la respuesta aceptada fue una de las más débiles (Disadvantages of Test Driven Development?), y la respuesta más modificada huele a alguien que podría estar escribiendo pruebas específicas.
inversión de tiempo grande: para el caso simple se pierde alrededor del 20% de la implementación real, pero para los casos complicados a perder 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 los casos complejos casos de prueba son más difícil de calcular, sugeriría en casos como el de tratar de utilizar código de referencia automática que se ejecutará en paralelo en el plazo versión de depuración/ prueba, en lugar de la prueba unitaria de casos más simples.
Si su prueba se está volviendo muy compleja, podría ser hora de revisar su diseño. TDD debería guiarlo por el camino unidades de código más pequeñas y menos complejas que funcionen juntas
A veces el diseño no está claro al principio y evoluciona a medida que avanza - esto le obligará a rehacer su prueba que generará un gran momento perder. 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 "Test Driven Design". TDD se trata de diseño, no de prueba. Para darse cuenta del valor de los beneficios de TDD, tiene unidad de disco su diseño de sus pruebas. Por lo que debe ser rehacer su código de producción para hacer sus pruebas pasan, no al revés como este punto sugiere
Ahora, el momento más upmodded: Disadvantages of Test Driven Development?
Al llegar al punto donde se tener 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 una especificación excesiva 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.
La idea errónea que a menudo veo es que TDD garantiza buenos resultados.
A menudo, las pruebas se cancelan por defectos de los requisitos, 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.
Estas son las cuestiones que en mi opinión son bastante controvertido y por lo tanto propensos a malentendidos:
En mi experiencia, la mayor ventaja es la producción mucho mejor código a costa de una gran cantidad de tiempo dedicado a escribir las 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.
Parece que la gente piensa que solo se debe probar un subconjunto importante de las características, 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 provocada por las pruebas incompletas: he visto que los sitios se caen porque la gente suponía que la Prueba Unitaria era suficiente para activar una implementación.
No hay necesidad de estructuras de burla 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.
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 las 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.
En mi humilde opinión El error más grande acerca de 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 agradable, pero la función se completará 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 no se gasta la corrección y la reparació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 errores 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 grave que debe corregirse rápidamente.
Estoy de acuerdo con su punto sobre el tiempo pasado frente al tiempo perdido. Descubrí que escribo código más rápido cuando puedo usar un marco de prueba y TDD. Me mantiene enfocado en la tarea y me dice exactamente dónde cometo errores. Paso mucho menos tiempo rascándome la cabeza. –
Simplemente lanzando otra respuesta en el bote.
Uno de los malentendidos más comunes es que su código está arreglado, 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é ...?
Bien El tipo de código que es fácil de probar es:
Si escribimos código como este, la prueba es un juego de dados. Lo interesante es que el código que es fácil de probar es, casualmente, mejor código.
mejor que en el más fácil de leer , más fácil de prueba, más fácil de entender , más fácil de depuración. Esta es la razón por la que TDD a menudo se describe como un ejercicio de diseño.
Si está trabajando con requisitos defectuosos, ningún proceso de desarrollo puede ayudarlo. Esto no es una idea errónea sobre TDD. –