historia - TDD. ¿Cuándo puedes seguir?
tdd vs bdd (13)
Al hacer TDD , ¿cómo saber "suficientes pruebas para esta clase / función"?
Es decir, ¿cuándo podría decir que ha completado las pruebas de todos los casos extremos?
Bueno, cuando no se puede pensar en más casos de falla que no funcionan como se esperaba.
Parte de TDD es mantener una lista de las cosas que desea implementar, y los problemas con su implementación actual ... así que cuando esa lista se acabe, básicamente está listo ...
Y recuerde, siempre puede regresar y agregar pruebas cuando descubra errores o nuevos problemas con la implementación.
Con Test Driven Development, escribirás una prueba antes de escribir el código que prueba. Una vez que haya escrito el código y la prueba haya pasado, entonces es hora de escribir otra prueba. Si sigues TDD correctamente, has escrito suficientes pruebas una vez que tu código hace todo lo que se requiere.
En cuanto a los casos extremos, tomemos un ejemplo como la validación de un parámetro en un método. Antes de agregar el parámetro a su código, crea pruebas que verifican que el código manejará cada caso correctamente. Luego puede agregar el parámetro y la lógica asociada, y asegurar que las pruebas pasen. Si piensa en más casos extremos, se pueden agregar más pruebas.
Al avanzar paso a paso, no tendrá que preocuparse por los casos límite cuando haya terminado de escribir su código, porque ya habrá escrito las pruebas para todos. Por supuesto, siempre hay un error humano, y es posible que se pierda algo ... Cuando ocurre esa situación, es hora de agregar otra prueba y luego corregir el código.
En cierto nivel, es una sensación visceral de
"¿Estoy seguro de que las pruebas detectarán todos los problemas que pueda pensar ahora?"
En otro nivel, ya tiene un conjunto de requisitos de usuario o sistema que deben cumplirse, por lo que puede detenerse allí.
Si bien uso la cobertura de código para decirme si no seguí mi proceso de TDD y para encontrar el código que puede eliminarse, no contaría la cobertura del código como una forma útil de saber cuándo parar. La cobertura de su código podría ser del 100%, pero si olvidó incluir un requisito, bueno, entonces realmente no ha terminado, ¿verdad?
Quizás una idea errónea sobre TDD es que tienes que saber todo lo que hay antes para probar. Esto está mal orientado porque las pruebas que resultan del proceso TDD son como un rastro de migas de pan. Ya sabe lo que se ha probado en el pasado y puede guiarlo hasta cierto punto, pero no le dirá qué hacer a continuación.
Creo que TDD podría considerarse como un proceso evolutivo. Es decir, comienzas con tu diseño inicial y su conjunto de pruebas. A medida que su código se deteriora en la producción, agrega más pruebas y el código que hace que esas pruebas pasen. Cada vez que agrega una prueba aquí y una prueba allí, también está haciendo TDD, y no cuesta tanto. No sabías que esos casos existían cuando escribiste tu primer conjunto de pruebas, pero ahora lo aprendiste y puedes verificar esos problemas con solo tocar un botón. Este es el gran poder de TDD, y una razón por la que lo defiendo tanto.
Siempre puede usar una herramienta de cobertura de prueba como EMMA ( http://emma.sourceforge.net/ ) o su complemento Eclipse EclEmma ( http://www.eclemma.org/ ) o similar. Algunos desarrolladores creen que la cobertura de prueba al 100% es un objetivo digno; otros no están de acuerdo.
Solo trata de llegar a la conclusión de que puedes hacer que algo falle. Valores nulos, valores fuera de rango, etc. Una vez que no puede encontrar nada fácilmente, simplemente continúe con otra cosa.
Si en el camino encuentra un nuevo error o encuentra una forma, agregue la prueba.
No se trata de cobertura de código. Esa es una medida peligrosa, porque el código está "cubierto" mucho antes de que se "pruebe bien".
Teóricamente debe cubrir todas las combinaciones de entrada posibles y probar que la salida sea correcta, pero a veces simplemente no vale la pena.
ese sentido común, no hay una respuesta perfecta. El objetivo de TDD es eliminar el miedo, si te sientes seguro de que lo has probado lo suficientemente bien, continúa ...
No olvide que si encuentra un error más adelante, primero escriba una prueba para reproducir el error, luego corríjalo, ¡así evitará que el cambio futuro lo rompa nuevamente!
Algunas personas se quejan cuando no tienen un X por ciento de cobertura ... algunas pruebas son inútiles, y una cobertura del 100% no significa que pruebes todo lo que pueda hacer que tu código se rompa, solo el hecho de que no se romperá por la forma en que usaste ¡eso!
tal vez me perdí algo en algún lugar del mundo de Agile / XP, pero mi comprensión del proceso fue que el desarrollador y el cliente especifican las pruebas como parte de la característica . Esto permite que los casos de prueba sustituyan la documentación de requisitos más formales, ayuda a identificar los casos de uso para la función, etc. Por lo tanto, ya finalizó las pruebas y la codificación cuando pasaron todas estas pruebas ... además de cualquier caso límite que piense de en el camino
Alberto Savoia dice que " si todas tus pruebas pasan, es probable que tu prueba no sea lo suficientemente buena ". Creo que es una buena manera de pensar en las pruebas: pregúntele si está haciendo casos límite, pase algún parámetro inesperado, etc. Una buena forma de mejorar la calidad de sus pruebas es trabajar con un par, especialmente un probador, y obtener ayuda sobre más casos de prueba. Combinar con probadores es bueno porque tienen un punto de vista diferente.
Por supuesto, puede usar alguna herramienta para hacer pruebas de mutación y obtener más confianza de sus pruebas. He usado Jester y mejora tanto mis pruebas como la forma en que las escribí. Considera usar algo como eso.
Saludos cordiales
Las pruebas en TDD cubren la especificación , de hecho, pueden ser un sustituto de una especificación. En TDD, las pruebas no se tratan de cubrir el código. Aseguran que el código cubre la especificación, porque el código no pasará una prueba si no cubre la especificación. Cualquier código adicional que tengas no importa.
Entonces, tiene suficientes pruebas cuando las pruebas parecen describir todas las expectativas que usted o los interesados tienen.
Muchos de los otros comentarios han dado en el clavo. ¿Te sientes seguro del código que has escrito dada la cobertura de tu prueba? A medida que su código evoluciona, ¿sus pruebas aún lo cubren adecuadamente? ¿Sus pruebas capturan el comportamiento y la funcionalidad previstos para el componente bajo prueba?
Debe haber un medio feliz A medida que agrega más y más casos de prueba, sus pruebas pueden volverse frágiles ya que lo que se considera un caso marginal cambia continuamente. Después de muchas de las sugerencias anteriores, puede ser muy útil obtener todo lo que se pueda pensar por adelantado y luego agregar nuevas pruebas a medida que el software crezca. Este tipo de cultivo orgánico puede ayudar a que sus pruebas crezcan sin todo el esfuerzo inicial.
No voy a mentir, pero a menudo me pongo vago cuando vuelvo a escribir pruebas adicionales. Podría perder esa propiedad que contiene 0 código o el constructor predeterminado que no me importa. A veces, no ser completamente anal acerca del proceso puede ahorrarle tiempo en áreas que son menos críticas (el mito del 100% de cobertura del código).
Debes recordar que el objetivo final es sacar un producto de primera clase y no matarte a tí mismo. Si tienes la sensación de que te falta algo, es probable que tengas y que necesites agregar más pruebas.
Buena suerte y feliz codificación.
Una prueba es una forma de describir con precisión algo que desea. Agregar una prueba expande el alcance de lo que desea, o agrega detalles de lo que desea.
Si no puede pensar en nada más que desee, o cualquier refinamiento de lo que desea, entonces pase a otra cosa. Siempre puedes volver más tarde.
El consejo de Kent Beck es escribir pruebas hasta que el miedo se convierta en aburrimiento. Es decir, hasta que ya no tenga miedo de que algo se rompa, suponiendo que comience con un nivel apropiado de miedo.