TDD. ¿Cuándo puedes seguir adelante?

Question

Al hacer TDD , cómo saber " eso es suficiente prueba para esta clase / característica " ;?

I.e. ¿Cuándo podría decir que completó la prueba de todos los casos de borde?

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 pase, es hora de escribir otra prueba. Si sigues TDD correctamente, has escrito suficientes pruebas una vez que el código hace todo lo que se requiere.

En cuanto a los casos de borde, tomemos un ejemplo como validar un parámetro en un método. Antes de agregar el parámetro a su código, cree pruebas que verifiquen que el código manejará cada caso correctamente. Luego, puede agregar el parámetro y la lógica asociada, y asegurarse de que las pruebas pasan. Si piensa en más casos de borde, se pueden agregar más pruebas.

Al hacerlo paso a paso, no tendrá que preocuparse por los casos perimetrales cuando termine de escribir su código, porque ya habrá escrito las pruebas para todos ellos. Por supuesto, siempre hay un error humano y es posible que se pierda algo ... Cuando se produce esa situación, es hora de agregar otra prueba y luego corregir el código.

Answer 2

El consejo de Kent Beck es escribir pruebas hasta que el miedo se convierta en aburrimiento. Es decir, hasta que ya no tengas miedo de que algo se rompa, asumiendo que comienzas con un nivel apropiado de miedo.

Answer 3

En algún nivel, es una sensación visceral de

  

" Estoy seguro de que las pruebas detectarán todos los problemas que se me ocurran   ahora? "

En otro nivel, ya tiene un conjunto de requisitos de usuario o sistema que deben cumplirse, por lo que podría detenerse allí.

Si bien utilizo la cobertura de código para decirme si no seguí mi proceso de TDD y para encontrar el código que se puede eliminar, no consideraría la cobertura de código como una forma útil de saber cuándo detenerme. Su cobertura de código podría ser del 100%, pero si olvidó incluir un requisito, bueno, entonces realmente no ha terminado, ¿verdad?

Quizás una idea falsa acerca de TDD es que tienes que saber todo por adelantado para probar. Esto está mal orientado porque las pruebas que resultan del proceso de TDD son como un rastro de migas de pan. 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 la TDD podría considerarse como un proceso evolutivo. Es decir, empiezas con tu diseño inicial y es un conjunto de pruebas. A medida que su código se estropea en la producción, agrega más pruebas y un código que hace que esas pruebas se aprueben. Cada vez que agrega una prueba aquí y una prueba allí, también está haciendo TDD, y no cuesta tanto. No sabía que existían esos casos cuando escribió su primer conjunto de pruebas, pero adquirió el conocimiento ahora y puede verificar esos problemas con solo tocar un botón. Este es el gran poder de TDD, y una de las razones por las que lo defiendo tanto.

Answer 4

Bueno, cuando no se te ocurran más casos de fallas que no funcionen como se pretendía.

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 agote, esencialmente habrá terminado ...

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

Answer 5

ese sentido común, no hay 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á futuros cambios para romperlo nuevamente!

Algunas personas se quejan cuando no tienen el X por ciento de cobertura ... algunas pruebas son inútiles, y una cobertura del 100% no significa que pruebe todo lo que puede hacer que su código se rompa, solo el hecho de que no se rompa para el ¡Cómo lo usaste!

Answer 6

Una prueba es una forma de describir con precisión algo que deseas. Agregar una prueba expande el ámbito de lo que desea, o agrega detalles de lo que desea.

Si no puede pensar en nada más de lo que desea, o cualquier refinamiento de lo que desea, entonces continúe con otra cosa. Siempre puedes volver más tarde.

Answer 7

Las pruebas en TDD tratan de cubrir la especificación , de hecho, pueden ser un sustituto para una especificación. En TDD, las pruebas no tratan de cubrir el código. Aseguran que el código cubra 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.

Por lo tanto, tiene suficientes pruebas cuando parece que describen todas las expectativas que usted o las partes interesadas tienen.

Answer 8

tal vez me perdí algo en algún lugar del mundo Agile / XP, pero mi entendimiento del proceso fue que el desarrollador y el cliente especificaron las pruebas como parte de la Característica . Esto permite que los casos de prueba sustituyan a la documentación de requisitos más formal, ayuda a identificar los casos de uso de la función, etc. Así que ya ha terminado la prueba y la codificación cuando todas estas pruebas pasan ... más cualquier otro caso límite que piense de a lo largo del camino

Answer 9

Alberto Savoia dice que " si todas sus pruebas pasan, es probable que su prueba sea no es lo suficientemente bueno " ;. Creo que es una buena manera de pensar acerca de las pruebas: pregunte si está haciendo casos extremos, pase algún parámetro inesperado y así sucesivamente. Una buena manera 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 los probadores es bueno porque tienen un punto de vista diferente.

Por supuesto, podría usar alguna herramienta para hacer pruebas de mutación y obtener más confianza de tus pruebas He usado Jester y mejora mis pruebas y la forma en que las escribí. Considera usar algo como eso.

Saludos cordiales

Answer 10

En teoría, debes cubrir todas las combinaciones de entrada posibles y probar que la salida es correcta, pero a veces simplemente no vale la pena.

Answer 11

Muchos de los otros comentarios han golpeado el clavo en la cabeza. ¿Se siente seguro acerca del código que ha escrito dada la cobertura de su prueba? A medida que su código evoluciona, ¿sus pruebas aún lo cubren adecuadamente? ¿Sus pruebas capturan el comportamiento deseado y la funcionalidad 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 a medida que lo que se considera un caso de borde cambia continuamente. Siguiendo muchas de las sugerencias anteriores, puede ser muy útil obtener todo lo que 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 tus pruebas crezcan sin el esfuerzo inicial.

No voy a mentir, pero a menudo me vuelvo perezoso cuando vuelvo a escribir pruebas adicionales. Puede que pierda la propiedad que contiene el código 0 o el constructor predeterminado que no me importa. A veces, no ser completamente anal sobre el proceso puede ahorrarle tiempo y áreas que son menos críticas (el mito de cobertura del código al 100%).

Debe recordar que el objetivo final es obtener un producto de primera calidad y no suicidarse con las pruebas. Si tiene la sensación de que está perdiendo algo, es probable que tenga y que necesite agregar más pruebas.

Buena suerte y feliz codificación.

Answer 12

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 similares. Algunos desarrolladores creen que una cobertura de prueba del 100% es un objetivo valioso; otros no están de acuerdo.

Answer 13

Solo intente encontrar todas las formas posibles dentro de la razón de que pueda causar que algo falle. Valores nulos, valores fuera de rango, etc. Una vez que no pueda encontrar nada fácilmente, simplemente continúe con otra cosa.

Si en algún momento te encuentras con un error nuevo o encuentras una manera, agrega la prueba.

No se trata de cobertura de código. Esa es una métrica peligrosa, porque el código está " cubierto " mucho antes de que se " se pruebe bien " ;.