TDD. ¿Cuándo puedes seguir?

Question

Al hacer TDD, ¿cómo saber "suficientes pruebas para esta clase/función"?

I.e. ¿Cuándo podrías decir que completaste las pruebas de todos los casos extremos?

Answer 1

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 límite, veamos 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 ir paso a paso, no tendrá que preocuparse por los casos extremos cuando haya terminado de escribir el 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.

Answer 2

Bueno, cuando no puede pensar en más casos de falla que no funcionan como se esperaba.

Parte de TDD es mantener una lista de cosas que quiere poner en práctica, y los problemas con su implementación actual ... así que cuando esa lista se agota, que son esencialmente de hecho ....

Y recuerda, siempre puede regresar y agregar pruebas cuando descubre errores o problemas nuevos con la implementación.

Answer 3

Siempre puede utilizar 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.

Answer 4

ese sentido común, no hay una respuesta perfecta. El objetivo de TDD es eliminar el miedo, si estás seguro de haberlo probado lo suficiente, continúa ...

No olvides que si encuentras un error más adelante, escribe primero una prueba para reproducir el error, luego corrige ¡así que evitará que cambios futuros lo vuelvan a romper!

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 lo hará la forma en que lo usaste!

Answer 5

Solo trata de inventar todos los motivos posibles para 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 la cobertura del código. Esa es una medida peligrosa, porque el código está "cubierto" mucho antes de que se "pruebe bien".

Answer 6

En algún nivel, es una primera impresión de

"Estoy seguro de que las pruebas se pondrá al día todos los problemas que se me ocurre ahora?"

En otro nivel, ya tienes un conjunto de requisitos de usuario o del sistema que se deben cumplir, por lo que podría detenerse allí.

Mientras que hago uso de la cobertura de código para decirme si no siguió mi proceso TDD y para encontrar el código que se puede eliminar, 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, también , entonces realmente no has terminado, ¿verdad?

Quizás una idea errónea sobre TDD es que tienes que saber todo por adelantado 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.

Answer 7

tal vez me perdí algo en algún lugar del mundo 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

Answer 8

Alberto Savoia says que "si pasan todas sus pruebas, es probable que su 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 mutation tests 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

Answer 9

Teóricamente se debe cubrir todas las posibles combinaciones de entrada y prueba de que la salida es correcta, pero a veces no es sólo vale la pena.

Answer 10

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 da pereza 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).

Tienes que 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.

Answer 11

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.

Answer 12

Pruebas en TDD son acerca de cubrir la especificación, de hecho, pueden ser un sustituto para 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.

De modo que tiene suficientes pruebas cuando las pruebas parecen describir todas las expectativas que usted o los interesados ​​tienen.

Answer 13

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.