¿Deberíamos excluir el código para el análisis de cobertura de código?

Estoy trabajando en varias aplicaciones, principalmente las heredadas. Actualmente, su cobertura de código es bastante baja: generalmente entre 10 y 50%.

Desde hace varias semanas, tenemos discusiones recurrentes con los equipos de Bangalore (la parte principal del desarrollo se realiza en alta mar en India) con respecto a las exclusiones de paquetes o clases para Cobertura (nuestra herramienta de cobertura de código, incluso si actualmente estamos migrando a JaCoCo).

Su punto de vista es el siguiente: como no escribirán ninguna prueba unitaria en algunas capas de la aplicación (1) , estas capas deberían simplemente excluirse de la medida de cobertura del código. En otras palabras, quieren limitar la medida de cobertura del código al código que se prueba o se debe probar .

Además, cuando trabajan en pruebas unitarias para una clase compleja, los beneficios, puramente en términos de cobertura de código, pasarán desapercibidos en una aplicación grande. Reducir el alcance de la cobertura del código hará que este tipo de esfuerzo sea más visible ...

El interés de este enfoque es que tendremos una medida de cobertura de código que indica el estado actual de la parte de la aplicación que consideramos comprobable .

Sin embargo, mi punto de vista es que de alguna manera estamos fingiendo las cifras. Esta solución es una manera fácil de alcanzar un mayor nivel de cobertura de código sin ningún esfuerzo. Otro punto que me molesta es el siguiente: si mostramos un aumento de cobertura de una semana a otra, ¿cómo podemos saber si esta buena noticia se debe al buen trabajo de los desarrolladores, o simplemente debido a nuevas exclusiones?

Además, no podremos saber exactamente qué se considera en la medida de cobertura del código. Por ejemplo, si tengo una aplicación de 10.000 líneas de código con un 40% de cobertura de código, puedo deducir que se prueba el 40% de mi base de código (2) . ¿Pero qué pasa si establecemos exclusiones? Si la cobertura del código ahora es del 60%, ¿qué puedo deducir exactamente? ¿Que se prueba el 60% de mi base de código "importante"? Cómo puedo

En lo que a mí respecta, prefiero mantener el valor de cobertura del código "real", incluso si no podemos estar contentos con él. Además, gracias a Sonar, podemos navegar fácilmente en nuestra base de código y conocer, para cualquier módulo / paquete / clase, su propia cobertura de código. Pero, por supuesto, la cobertura del código global seguirá siendo baja.

¿Cuál es tu opinión sobre ese tema? ¿Cómo te va en tus proyectos?

Gracias.

(1) Estas capas generalmente están relacionadas con los beans UI / Java, etc.

(2) Sé que eso no es cierto. De hecho, solo significa que el 40% de mi código base

Generalmente excluyo el código generado automáticamente, como los clientes WCF que Visual Studio genera. Por lo general, hay muchas líneas de código allí y nunca las vamos a probar. Esto hace que sea muy desmoralizante aumentar las pruebas en una gran porción de código en otro lugar y solo aumentar la cobertura del código en un 0.1%.

También excluiré las interacciones de la capa de datos, siempre y cuando el equipo pueda decir con certeza que esta capa es lo más delgada posible. Si bien puede argumentar que, si la capa es delgada, no tendrá un efecto masivo, deja muchos componentes en el informe de cobertura con un 0% en contra de ellos, por lo que no necesariamente notamos los que necesitamos de qué preocuparse realmente. La capa de interfaz de usuario se podría argumentar de manera similar, dependiendo del marco que se utilice.

Pero, como contrapunto, también excluiré las pruebas unitarias. Siempre deben tener una cobertura de ~ 100% y representan un gran porcentaje de la base del código, sesgando peligrosamente las cifras hacia arriba.

Buena pregunta. En general, tiendo a excluir el código de la cobertura de código por algunos motivos, por ejemplo, es:

• generado
• heredado (ya no se actualiza)
• aquí viene: ciertas capas, no tengo la intención de probar

¿Por qué el último punto? Creo que es una buena práctica concentrarse en las cosas que me importan, mientras suprimo las distracciones. Si no tiene la intención de probar la capa de interfaz de usuario, ¿por qué tenerla en cuenta? Solo desviaría la atención de la parte importante de su software: la lógica empresarial.

PERO:

1. Debe tener una buena razón, por qué excluir una determinada capa de las pruebas unitarias (puede haber preguntas: de su jefe, sus compañeros de equipo, la prensa ;-)
2. Si desea que prueben estas capas, debe incluirlas en las estadísticas para mostrar a todo el equipo, todos los días, que es importante y debe hacerse.

Finalmente: no tomes los números demasiado en serio. La cobertura del 30% puede probar un software sólido como una roca, cuando es la parte esencial de él.

Tiendo a estar de acuerdo con usted e incluir todo el código relevante en las métricas de cobertura de código (y Sonar en general). Incluso si no planea probar algunas partes del código (en el futuro previsible), las métricas deben reflejar el estado real. Esto lo obliga a tener una razón convincente para no escribir pruebas para una parte significativa de la base de código. Eventualmente (una vez más, las partes más importantes del código ya están cubiertas) puede reconsiderar o elegir una forma diferente de eliminar esta disonancia, por ejemplo, refactorizando el código en cuestión para que sea comprobable o migrar toda la lógica de él a un parte diferente y comprobable de la base de código, o incluso para eliminar la capa completa por completo (si no vale la pena probar una capa, ¿tiene alguna razón suficiente para existir?)

En mis proyectos actuales, también incluimos todo el código en las métricas, con una excepción: el código generado, que genera montones de advertencias de análisis estático. Como este código generalmente consiste en clases de POD enormes sin ninguna lógica, de todos modos no hay nada que probar allí.

Ahora no estoy muy familiarizado con las herramientas de cobertura de código que está utilizando ni estoy familiarizado con los beans de Java, pero por lo que dice que están relacionados con la interfaz de usuario.

Con mi conocimiento limitado, tengo esto que decir:

1. No permita que los números de cualquier tipo de herramientas de prueba obstaculicen sus pruebas.
2. Si las clases son complejas y no son probables por unidad, siempre es una buena idea re-factorizarlas en clases más compactas y comprobables. Requerirá mucho esfuerzo y dedicación, pero pagará a largo plazo.
3. Probar los componentes de la interfaz de usuario puede ser difícil, pero aún puede probar la función que realizan esos componentes.
4. Si está haciendo un proyecto basado en la web, puede usar QUnit para probar unitariamente todo el código del lado del cliente.

En general, debe tener en cuenta que la cobertura del código es solo un número, y la alta cobertura del código no indica buenas pruebas. Concéntrese en hacer que las bibliotecas principales sean más robustas y comprobables en lugar de apuntar a un porcentaje más alto.

Algunas exclusiones tienen sentido (código de placa de caldera que no tiene un impacto real o potencial de impacto en el funcionamiento correcto de su proyecto). Aún así, recopilar la cobertura del código como una métrica no tiene sentido porque de todos modos no le dice nada útil. La cobertura del 100% del código no es un objetivo real, y los números de cobertura bajos también pueden no ser malos dependiendo del proyecto, podría ser posible que la cobertura del código del 20-30% cubra todo lo que vale la pena probar. la cobertura del código solo le indica que el X% de su código que vale la pena cubrir en realidad es mediante algún tipo de prueba de calidad desconocida.

Sugiero informar un conjunto de métricas para cada capa de su código. Estas métricas deben incluir información de tamaño (p. Ej., LoC, número de bibliotecas, número de clases o métodos, etc.), información de prueba (p. Ej., Cobertura) e información de errores (p. Ej., Buscar y corregir tasas).

Sus capas excluidas tendrán 0% de cobertura, y sus áreas probadas tendrán el 60% de cobertura que mencionó. La información sobre el tamaño permitirá a las personas comprender cuánto se prueba o no se prueba. La información del error le informará si tal vez debería crear pruebas para las capas excluidas, y si sus pruebas existentes están funcionando.

Es fácil para las organizaciones de software centrarse demasiado en la pureza de las métricas. No hacemos métricas, hacemos buen software. Una métrica que lo ayuda a entregar software de alta calidad de manera oportuna es la métrica más honesta y pura que existe.