2010-07-23 16 views
25

me he dado cuenta de que a pesar de que tengo un montón de prueba unitaria en nuestro código Python, cuando trazo la prueba utilizando los métodos descritos aquí:¿Garantiza la cobertura del código en las pruebas unitarias?

traceit

me parece que hay ciertas líneas de código que son nunca ejecutado Actualmente examino los registros de seguimiento para identificar bloques de código que nunca se ejecutan, y luego trato de encontrar diferentes casos de prueba para ejercitar estos bloques en particular. Como se puede imaginar, esto lleva mucho tiempo y me preguntaba si estamos haciendo esto de la manera incorrecta y si todos ustedes tienen otros consejos o sugerencias para tratar este problema, que estoy seguro debe ser común a medida que se convierte el software. suficientemente complejo.

Respuesta

28

coverage.py es una herramienta muy útil. Entre otras cosas, proporciona branch coverage.

+11

Esta respuesta sería más beneficiosa si proporcionó un breve ejemplo de cómo usar 'coverage.py'. – SimplyKnownAsG

+6

@SimplyKnownAsG La página vinculada tiene una sección Inicio rápido en el centro y la parte delantera, e incluye el uso de la muestra. En lugar de copiar y pegar documentación que está sujeta a cambios a medida que salen nuevas versiones, creo que es mejor simplemente vincular. –

+1

Cómo usar 'coverage.py': https://github.com/audreyr/how-to/blob/master/python/use_coverage_with_unittest.rst – dm295

18

¿Tiene un mandato de la administración para ser dogmático sobre la obtención de la cobertura del código del 100% con sus casos de prueba? Si no, ¿crees que tocar cada línea de código es la forma más efectiva de encontrar errores en tu código? Asumiendo que no tienes recursos infinitos de tiempo y personas, probablemente deberías concentrarte en probar razonablemente todo tu código no trivial con énfasis en las partes que los desarrolladores saben que son difíciles de escribir o propensas a errores.

Aunque la cobertura del código es excelente porque seguramente no se puede decir que una parte del código se ha probado hasta que se haya tocado, simplemente no equivale a tocar un trozo de código para llamarlo probado. No estoy en contra de la cobertura de código, pero es demasiado fácil caer en el uso de la cobertura de código como la métrica para saber cuándo se completa la prueba. Creo que eso sería un error.

+7

Este es un excelente comentario. En mi situación, tenemos científicos, no programadores, escribiendo el código de Python. Como resultado, aunque los científicos son muy inteligentes, el código está muy mal estructurado. Esto significa que la integración final y las pruebas son una pesadilla, y tenemos que trabajar demasiado para descubrir problemas graves durante esta fase. Intento que escriban mejores casos de prueba para el código del que cada uno es responsable y planeo usar la cobertura del código como una forma de calificar las pruebas que integran. Puedo entender que no se debe tocar el 100% del código, pero sería útil. – reckoner

+0

Tener una cobertura del 100% no es garantía de suficientes pruebas, pero el hecho de no tenerlas es, por lo general, indicativo de que no se han realizado suficientes pruebas. Tampoco olvidemos que el módulo de cobertura permite comentarios como '# pragma: no cover' y' # pragma: no branch'. –

Cuestiones relacionadas