Medir la cobertura del código solo en el nuevo código

Question

Estamos buscando una forma creativa de medir la cobertura del código en un código nuevo separado del código existente. Tenemos un gran proyecto heredado y queremos comenzar a obtener un 90% de cobertura en cualquier nueva funcionalidad. Nos gustaría una manera de ver fácilmente un informe que filtra cualquier código anterior para asegurarse de que la nueva funcionalidad cumpla con nuestro objetivo. Obviamente, aún buscamos una cobertura global creciente en el proyecto, pero necesitamos una forma no manual para darnos su opinión sobre la nueva actividad del código. Tenemos esto trabajando para el análisis estático ya que podemos ver las fechas en los archivos fuente. Como Cobertura está analizando los archivos de clase, tienen nuevas fechas y esta técnica no funciona.

¿Alguna idea?

Pila:

Java 1.5 JUnit Cobertura Hudson

Answer 1

echar un vistazo a emma.sourceforge y asociada Eclipse plug-in here (si está utilizando Eclipse)

creo que esta herramienta puede responder a su necesidad seleccionando exactamente qué probar para la cobertura.

Answer 2

Tuvimos una situación similar ... queríamos un código nuevo probado pero no pudimos probar todos los códigos antiguos a la vez. Lo que hicimos no es exactamente lo que nos pidió, pero puede darle una idea.

Tenemos un archivo llamado linecoverage.standard, y un archivo llamado branchcoverage.standard que vive en el servidor de compilación (y copias locales). Tienen un número dentro con los límites actuales de cobertura de línea y sucursal. Si el código registrado está por debajo del estándar, falla la compilación. Si está en el estándar pasa la construcción. Si está ARRIBA del estándar, se escribe un nuevo estándar igual a la cobertura actual.

Esto significa que nuestra cobertura de código nunca empeorará y debería subir lentamente. Si el nuevo código es del 90%, la cobertura seguirá aumentando. También puede establecer un objetivo como elevar el estándar en 1 cada semana hasta que llegue a su objetivo final (90%). Tener que agregar algunas pruebas a la semana al código anterior no es una mala idea, si se extiende a lo largo del tiempo suficiente.

Nuestra cobertura actual es de hasta el 75% ish ... bastante buena desde una tasa del 0% hace menos de un año.

Answer 3

Lo hice para un gran proyecto de C++ usando svn blame combinado con la salida de gcov. Si comprime esos dos resultados juntos, tiene información de revisión e información de cobertura para cada línea. De hecho, cargué todo esto en una base de datos para hacer consultas (por ejemplo, , mostrarme todas las líneas descubiertas escritas por joe desde r1234). Si solo quiere un número agregado, puede evitar contar las líneas "viejas" descubiertas en su total.

Answer 4

IMO la mejor opción es dividir la base de código en secciones "nuevas" y "heredadas". A continuación, ejecute el análisis de cobertura de prueba solo en la sección "nueva" o ignore los resultados de la sección "anterior".

Las dos mejores maneras de lograr esto son a) dividir la base de código en dos árboles de origen (dos proyectos con una dependencia entre), o b) mantener dos jerarquías de paquete separadas en un solo proyecto.

Probablemente sean preferibles dos proyectos separados, pero podría no ser posible si existe una dependencia cíclica entre la base de código heredada y la nueva base de código (el código antiguo depende del código nuevo y el código nuevo depende del código anterior). Si puede administrarlo, una dependencia unidireccional entre el código antiguo y el nuevo también hará que la base de código combinada sea más fácil de comprender.

Una vez que haya hecho esto, ajuste la cobertura para que solo analice los bits que desea o, al menos, concéntrese en la parte "nueva" de la base de código. Un consejo adicional es que en este esquema, es mejor mover trozos de código de la sección "heredada" a la sección "nueva" a medida que los refactoriza/agrega pruebas (si el código se mueve con frecuencia en la otra dirección, no es así bueno :-).

Answer 5

Lo hicimos de la siguiente manera usando la propiedad sonar.exclusions: Utilizamos Sonar para mostrar los informes de cobertura de código (informados por Cobertura).

a) Identifique las clases en las que no desea informe de cobertura (Legacy classes) Use su cliente de línea cmd SCM. por ejemplo: archivos p4 // depot/... @ 2000/01/01, @ 2013/07/13 git log --until = "Hace 5 días"

directo esta lista en un archivo. Tendrá que hacer algunos análisis basados ​​en la herramienta SCM que utiliza y su archivo de destino debe contener un nombre de archivo por línea.

eg. the destination file is excludeFile.list should look like below: 
abc.java 
xyz.java 
... 

b) Ahora ... cuando se integre con Sonar (de Jenkins Job), utilice la siguiente propiedad.

-Dsonar.exclusions=<filename> 

Y su informe final en la cobertura del sonar contiene sólo sus nuevas clases (añadido después de 07/13 en el ejemplo anterior).