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

Question

Regularmente alcanzo el 100% de cobertura de bibliotecas usando TDD, pero no siempre, y siempre parece haber partes de aplicaciones sobrantes que no han sido probadas y descubiertas.
Luego están los casos en que se inicia 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 para que al menos haya mejorado la cobertura de.
Supongo que está midiendo la cobertura durante la prueba unitaria, pero indique si está utilizando otras técnicas.

Answer 1

Borrar código.

Esto no es sarcástico, pero en realidad es serio. Cada vez que veía la cantidad más pequeña de duplicación de código o incluso código que no podía ejecutar, lo borraba. Esta mayor cobertura y mayor capacidad de mantenimiento.

Debo señalar que esto es más aplicable para aumentar la cobertura de las viejas bases de códigos frente a las nuevas bases de códigos.

Answer 2

Utilizamos Perl, por lo que Devel::Cover nos ha sido muy útil. Muestra la cobertura por extracto, la cobertura de sucursal y la cobertura condicional durante la prueba unitaria, así como cosas como la cobertura POD. Usamos 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.

EDIT: Para ampliar un poco las cosas:

• Si la cobertura condicional no es completa, examinar las condiciones de interdependencia. Si está allí, refactor. Si no es así, debería poder extender sus pruebas para cumplir con todas las condiciones.
• Si la cobertura condicional y de sucursal parece completa pero la cobertura de la declaración no lo es, o ha escrito las condiciones incorrectas (por ejemplo, siempre regresando temprano de un sub cuando no era su intención) o tiene un código adicional que puede ser eliminado con seguridad.

Answer 3

Las dos cosas que tenían el mayor impacto en los proyectos que he trabajado eran:

1. Periódicamente "recordar" el equipo de desarrollo de actualy aplicar pruebas de unidad, y la revisión de cómo escribir pruebas eficaces.
2. Generando un informe de la cobertura general de la prueba, y circulando eso entre los gerentes de desarrollo.

Answer 4

Supongo que ha leído "Code covered vs. Code Tested", ¿verdad?

Como se indica en esa pregunta,

cobertura bloque Incluso con 100% + cobertura de arco 100% + 100% código de línea recta libre para en-uno-ruta de menor error, habrá seguir siendo datos de entrada que ejecuten rutas/bucles de forma que muestren más errores.

Ahora, yo uso eclemma, basado en EMMA y que la herramienta de código de cobertura explica por qué el 100% código no siempre es posible: a causa de partially covered lines debido a:

• ramas implícitos en el mismo línea.
• Código de constructor compartido.
• Ramales implícitos debido a bloques finally.
• Ramas implícitas debido a un Class.forName oculto().

Por lo tanto, todos esos 4 casos podrían ser buenos candidatos para la refactorización que conducen a una mejor cobertura del 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 realizar alguna refactorización, incluido algún código para eliminar;;

Answer 5

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

Antecedentes: tenemos una combinación de código heredado y nuevo. Tratamos de probar la unidad/integración lo más 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 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 en contra del 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 serán puente entre versiones: probarán el código heredado pero luego, más tarde, el nuevo código. es decir, sirven como pruebas de regresión, en cierto sentido.