¿Qué técnicas ha utilizado con éxito para mejorar la cobertura del código?

Question

Regularmente obtengo una cobertura del 100% de las bibliotecas que usan TDD, pero no siempre, y siempre parece que quedan partes de aplicaciones que no han sido probadas y descubiertas.
Luego están los casos en los que comienza con un código heredado que tiene muy pocas pruebas y muy poca cobertura.

Indique cuál es su situación y qué ha funcionado que al menos mejoró la cobertura.
Supongo que está midiendo la cobertura durante las pruebas unitarias, pero diga si está utilizando otras técnicas.

Answer 1

Eliminar código.

Esto no es sarcástico, pero en realidad es serio. Cada vez que veía la menor cantidad de código duplicado o incluso código que no podía ejecutar, lo eliminaba. Esto aumentó la cobertura y aumentó la capacidad de mantenimiento.

Debo tener en cuenta que esto es más aplicable para aumentar la cobertura de las bases de código antiguas en comparación con las bases de código nuevas.

Answer 2

Supongo que has leído " Código cubierto vs. Código probado " , verdad?

Como se indica en esa pregunta,

  

Incluso con 100% de cobertura de bloque + 100% de cobertura de arco + 100% de código de línea recta libre de errores para al menos una ruta, todavía habrá datos de entrada que ejecutan rutas / bucles de manera que exhiban más errores.

Ahora, uso eclemma , basado en EMMA y esa herramienta de cobertura de código explica por qué el código del 100% no siempre es posible: debido a líneas parcialmente cubiertas debido a:

• Ramas implícitas en la misma línea.
• Código de constructor compartido.
• Ramas implícitas debido a bloques finalmente.
• Ramas implícitas debido a un Class.forName () oculto.

Por lo tanto, todos esos 4 casos podrían ser buenos candidatos para refactorizar, lo que conduce a una mejor cobertura de código.

Ahora, estoy de acuerdo con la respuesta de Frank Krueger. Algunos códigos no cubiertos también pueden ser una indicación de que se debe hacer alguna refactorización, incluido algún código para eliminar realmente;)

Answer 3

Las dos cosas que tuvieron el mayor impacto en los proyectos en los que he trabajado fueron:

1. Periódicamente " recordando " el equipo de desarrollo implementará pruebas unitarias y revisará cómo escribir pruebas efectivas.
2. Generando un informe de cobertura de prueba general y distribuyéndolo entre los gerentes de desarrollo.

Answer 4

Utilizamos Perl, así que Devel :: Cover ha sido muy útil para nosotros. Muestra la cobertura por estado de cuenta, la cobertura de sucursal y la cobertura condicional durante las pruebas unitarias, así como también la cobertura POD. Utilizamos la salida HTML con greens fáciles de reconocer para "100%", a través de amarillo y rojo para niveles más bajos de cobertura.

EDITAR: Para ampliar un poco las cosas:

• Si la cobertura condicional no está completa, examine las condiciones para la interdependencia. Si está allí, refactorizar. Si no es así, debería poder extender sus pruebas para cumplir con todas las condiciones.
• Si la cobertura condicional y de rama se ve completa, pero no lo es la cobertura del estado de cuenta, o bien escribió las condicionales como erróneas (por ejemplo, siempre regresó antes de un submarino cuando no era su intención) o tiene un código adicional que puede ser eliminado de forma segura.

Answer 5

FIT testing ha mejorado nuestra cobertura de código. Ha sido genial porque es una táctica completamente diferente.

Antecedentes: tenemos una mezcla de código heredado y nuevo. Intentamos probar la unidad / integración lo más nuevo posible, pero debido a que estamos migrando a Hibernate / Postgres y lejos de un OODB, no tiene mucho sentido probar el código heredado.

Para aquellos que no saben, FIT es una forma de probar el software desde la perspectiva del usuario. Esencialmente, puede especificar el comportamiento deseado en las tablas HTML: las tablas especifican las acciones contra el software y los resultados deseados. Nuestro equipo escribe 'código de pegamento' (también conocido como prueba FIT) que asigna las acciones a las llamadas contra el código. Tenga en cuenta que estas pruebas operan en una vista 'desde el espacio' en comparación con las pruebas unitarias.

Usando este enfoque, hemos aumentado nuestra cobertura de código en varios puntos porcentuales. Una ventaja adicional es que estas pruebas se unirán a través de las versiones: probarán el código heredado pero luego, más adelante, el nuevo código. es decir, sirven como pruebas de regresión, en cierto sentido.