¿Cómo hacer un análisis significativo de cobertura de código de mis pruebas unitarias?

Gestiono las pruebas para un sistema de precios financieros muy grande. Recientemente, nuestros HQ han insistido en que verifiquemos que cada parte de nuestro proyecto tiene una prueba significativa en su lugar. Como mínimo, quieren un sistema que garantice que cuando cambiemos algo podamos detectar cambios no intencionales en otros subsistemas. Preferiblemente, quieren algo que valide la corrección de cada componente de nuestro sistema.

¡Obviamente va a ser bastante trabajo! Podría llevar años, pero para este tipo de proyecto vale la pena.

Necesito averiguar qué partes de nuestro código no están cubiertas por ninguna de nuestras pruebas unitarias. Si supiera qué partes de mi sistema no se probaron, podría comenzar a desarrollar nuevas pruebas que finalmente se acercarían a mi objetivo de una cobertura completa de las pruebas.

Entonces, ¿cómo puedo dirigir este tipo de análisis? ¿Qué herramientas están disponibles para mí?

Yo uso Python 2.4 en Windows 32bit XP

ACTUALIZACIÓN0:

Solo para aclarar: tenemos un conjunto de pruebas de unidad muy completo (más un conjunto de pruebas completo y extenso que está fuera del alcance de este ejercicio). También tenemos una plataforma de integración continua muy estable (construida con Hudson) que está diseñada para dividir y ejecutar pruebas unitarias estándar de Python en nuestras instalaciones de prueba: Aproximadamente 20 PC construidas según las especificaciones de la compañía.

El objetivo de este ejercicio es tapar los huecos en nuestra suite python unittest suite (solo) para que cada componente tenga algún grado de cobertura de unittest. Otros desarrolladores se responsabilizarán de los componentes que no sean Python del proyecto (que también están fuera del alcance).

"Componente"es intencionalmente vago: en algún momento será una clase, otra vez un módulo completo o un conjunto de módulos. Incluso podría referirse a un solo concepto financiero (por ejemplo, un solo tipo de opción financiera o un modelo financiero utilizado por muchos tipos de opción) Esta torta se puede cortar de muchas maneras.

"Significativo"las pruebas (para mí) son las que validan que la función hace lo que el desarrollador pretendía originalmente. No queremos simplemente reproducir las pruebas en python puro. A menudo, la intención del desarrollador no es inmediatamente obvia, de ahí la necesidad de investigar y aclarar cualquier cosa. que parece vago y luego consagra este conocimiento en una prueba unitaria que hace que la intención original sea bastante explícita.

Respuestas a la pregunta(5)

Su respuesta a la pregunta