TDD y Cobertura de código

Question

Estoy a punto de comenzar a buscar en el desarrollo con la ayuda de la cobertura de código, y me pregunto cómo encaja típicamente con el desarrollo impulsado por prueba.

¿Es la cobertura del código una idea de último momento? ¿Su proceso sea algo así como

1. escribir una prueba para la funcionalidad a implementar
2. Ejecutar prueba, asegúrese de que fallan
3. Implementar funcionalidad
4. Ejecutar prueba, garantizar que superan
5. Comentario más pruebas para la funcionalidad hasta que se obtenga una cobertura de código del 100% (o cerca)

¿O ejecuta la cobertura del código al final una Después de varias piezas funcionales, ¿se han implementado y luego regresan y funcionan para lograr una cobertura del 100%?

La tercera opción que puedo pensar se esfuerza hacia una cobertura del 100% incluso antes de implementar la funcionalidad.

¿Cuál de estos es el más común y cuáles son los beneficios?

Answer 1

No realiza pruebas hasta que se alcanza la cobertura del 100% del código. Si ha estado siguiendo TDD, entonces está el código no que alguna vez escribió sin ser requerido por una prueba, por lo que siempre debe tener una cobertura cercana al 100%.

En su lugar, escribe pruebas hasta que todas las pruebas pasan, y hasta que se hayan escrito todas las pruebas requeridas. Esto implicará que se ha escrito todo el código requerido, ya que solo tendrá un código escrito si fue requerido por una prueba.

Answer 2

Con TDD, casi siempre debe tener una cobertura cercana al 100% cuando desarrolle un nuevo código, ya que no desarrolla ningún código que no necesite pasar las pruebas. Solo cuando crea que el código es tan simple que no necesita una prueba (por ejemplo, como una propiedad automática en C#), debe tener un código que no esté específicamente cubierto. Puede, a través de la refactorización, a veces introducir bloques que no son necesarios o cambiar el código de forma inesperada, por lo que es posible que desee utilizar la cobertura en ese punto para asegurarse de no haber introducido accidentalmente el código no probado. Aparte de eso, diría que lo uso más como un control de cordura y hago análisis de cobertura periódicamente por las mismas razones. También puede ser muy útil cuando se rompe tu disciplina y te olvidas de trabajar de manera TDD.

Answer 3

Recuerde que puede tener una prueba que realmente utiliza un código que se cubre por casualidad. Debe tener cuidado con esto, especialmente al iniciar TDD. Oh, estoy en esta función y sé que tendré que agregar esta pequeña menta fina mientras estoy en ello, ¿por qué no otra casa de la moneda? Antes de que te des cuenta, tienes un montón de código no probado.

prueba de escritura: Falla Código Comentario: Pase Refactor: Pass

Hacia arriba