Close

¿Qué es la cobertura de código?

En este artículo, aprenderás a empezar a usar la cobertura de código, a encontrar la herramienta adecuada y a hacer los cálculos.

Foto de Sten Pittet
Sten Pittet

Escritor colaborador


La cobertura de código es un parámetro con el que podrás saber qué parte de tu fuente se ha sometido a pruebas. Es muy útil para evaluar la calidad del conjunto de pruebas. Ahora, vamos a ver cómo dar los primeros pasos con tus proyectos.

¿Cómo se calcula la cobertura de código?


Las herramientas de cobertura de código utilizarán uno o varios criterios para determinar cómo se ejecutó o no tu código durante la ejecución del conjunto de pruebas. Estos son algunos de los parámetros que es habitual encontrar en los informes de cobertura:

  • Cobertura de funciones: la cantidad de funciones definidas que se abarcan.
  • Cobertura de instrucciones: cuántas instrucciones del programa se han ejecutado.
  • Cobertura de ramas: cuántas ramas de las estructuras de control (instrucciones IF, por ejemplo) se han ejecutado.
  • Cobertura de condiciones: en cuántas subexpresiones booleanas se ha comprobado el valor verdadero o falso.
  • Cobertura de líneas: cuántas líneas de código fuente se han probado.

Estas métricas suelen estar representadas por el número de elementos sometidos a prueba, los elementos que se encuentran en tu código y un porcentaje de cobertura (elementos probados/elementos encontrados).

Estos parámetros están relacionados, pero son diferentes. En el script de abajo, una función JavaScript comprueba si un argumento es un múltiplo de 10 o no. Más adelante, usaremos esa función para comprobar si 100 es o no un múltiplo de 10. Te ayudará a entender la diferencia entre la cobertura de funciones y la cobertura de ramas.

Ver la solución

Desarrolla y pon en marcha software con Open DevOps

Material relacionado

Pruebas automatizadas para DevOps

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else    return false; }   console.log(isMultipleOf10(100));


Podemos usar la herramienta de cobertura istanbul para ver cuánto código se ejecuta al ejecutar este script. Después de ejecutar la herramienta de cobertura, obtenemos un informe de cobertura que muestra nuestros parámetros de cobertura. Podemos ver que, mientras que nuestra cobertura de funciones es del 100 %, la cobertura de ramas es de solo un 50 %. También podemos ver que la herramienta de cobertura de código istanbul no calcula un parámetro de cobertura de condiciones.

Obtener un informe de cobertura en la línea de comandos

Esto es así porque, cuando ejecutamos nuestro script, la instrucción ELSE no se ha ejecutado. Si quisiéramos obtener una cobertura del 100 %, se podría agregar otra línea (en esencia, otra prueba) para asegurarnos de que se utilicen todas las ramas de la instrucción IF.

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else     return false; }   console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.  


Una segunda ejecución de nuestra herramienta de cobertura mostrará ahora que el 100 % de la fuente está cubierto gracias a las dos instrucciones console.log() del final.

Conseguir una cobertura del 100 % en todos los criterios

En este ejemplo, solo estábamos registrando resultados en el terminal, pero el mismo principio se aplica al ejecutar tu conjunto de pruebas. Tu herramienta de cobertura de código supervisará la ejecución de tu conjunto de pruebas y te dirá cuántas instrucciones, ramas, funciones y líneas se han ejecutado dentro de las pruebas.

istanbul para JavaScript puede mostrar un informe detallado de la cobertura para cada ruta

Primeros pasos en la cobertura de código


Elige la herramienta adecuada para tu proyecto

Puede que encuentres varias opciones para crear informes de cobertura en función de los lenguajes que utilices. Estas son algunas herramientas populares:

Herramientas como istanbul arrojarán los resultados directamente en tu terminal, mientras que otras pueden generar un informe HTML completo con el que explorar en qué parte del código falta cobertura.

¿Qué porcentaje de cobertura es el que debes buscar?

En la cobertura de código no hay soluciones milagrosas. Además, incluso con un alto porcentaje de cobertura, podrías seguir teniendo problemas si no se prueban partes críticas de la aplicación o si las pruebas existentes no son lo suficientemente robustas como para detectar correctamente los fallos de antemano. Dicho esto, generalmente se acepta que la cobertura del 80 % es el objetivo que se debe perseguir. Tratar de alcanzar una cobertura mayor puede resultar costoso y no siempre genera unas ventajas que justifiquen el esfuerzo.

Cuando ejecutes por primera vez la herramienta de cobertura, puedes observar un porcentaje bastante bajo de cobertura. Si acabas de empezar con las pruebas, es algo normal y no deberías sentirte presionado por conseguir una cobertura del 80 % enseguida. Si te precipitas, podrías empujar al equipo a crear pruebas centradas en las líneas del código, en lugar de atender a los requisitos empresariales de la aplicación.

Por ejemplo, en el caso anterior alcanzamos una cobertura del 100 % probando si 100 y 34 eran múltiplos de 10. Pero ¿y si la función se llamase con una letra en lugar de con un número? ¿Obtendríamos un resultado verdadero/falso? ¿O sería una excepción? Es importante que des tiempo al equipo para pensar en pruebas desde la perspectiva del usuario y no solo fijándose en las líneas de código. La cobertura de código no te dirá si te faltan cosas en la fuente.

Comienza centrándote en las pruebas unitarias

Las pruebas unitarias comprueban que los métodos individuales de las clases y los componentes utilizados por la aplicación funcionan. Por lo general, son baratas de implementar y rápidas de ejecutar, y dan una garantía general de que la base de la plataforma es sólida. Una forma sencilla de aumentar rápidamente la cobertura de código es añadir pruebas unitarias que, por definición, deberían ayudarte a garantizar que el conjunto de pruebas llega a todas las líneas de código.

Utiliza informes de cobertura para detectar fallos críticos en las pruebas

Enseguida tendrás tantas pruebas en el código que será imposible saber qué parte de la aplicación se comprueba durante la ejecución del conjunto de pruebas. Cuando haya compilaciones defectuosas sabrás que se ha roto algo, pero te será difícil saber qué componentes han superado las pruebas.

Precisamente en este punto es donde los informes de cobertura pueden proporcionar orientación práctica para el equipo. La mayoría de las herramientas permiten examinar los informes de cobertura para ver los elementos que no cubren las pruebas y luego utilizarlos para identificar partes críticas de la aplicación que todavía estén por probar.

SimpleCov para Ruby puede mostrar qué métodos no han sido probados

Cuando estés listo, integra la cobertura de código en tu flujo de integración continua

Cuando establezcas un flujo de trabajo de integración continua (CI), puede que empieces a recibir fallos de las pruebas si no alcanzas un porcentaje suficientemente alto de cobertura. Por supuesto, como se ha dicho ya, no sería razonable establecer un umbral demasiado alto y es probable que una cobertura del 90 % ocasione muchos fallos en la compilación. Si tu objetivo es una cobertura del 80 %, podrías establecer un umbral de fallo del 70 % como red de seguridad para tu cultura de CI.

Como tantas veces, procura no enviar el mensaje equivocado, ya que presionar al equipo para que alcance una buena cobertura podría llevar a malas prácticas de pruebas.

Una buena cobertura no equivale a buenas pruebas

Para conformar una buena cultura de pruebas, tu equipo debe saber cómo debería comportarse la aplicación cuando se usa correctamente, pero también cuando alguien intenta forzarla. Las herramientas de cobertura de código ayudan a saber dónde mirar, pero no indican si tus pruebas son lo suficientemente robustas ante comportamientos inesperados.

Conseguir una buena cobertura es un objetivo excelente, pero debe combinarse con un conjunto de pruebas sólido que garantice el estado de las clases y que verifique la integridad del sistema.

Conoce mejor los Distintos tipos de pruebas de software.

Sten Pittet
Sten Pittet

Llevo 10 años en el negocio del software desempeñando diversas funciones, desde el desarrollo hasta la gestión de productos. Tras pasar los últimos 5 años en Atlassian trabajando en herramientas para desarrolladores, ahora escribo sobre compilación de software. Fuera del trabajo, me dedico a perfeccionar mis habilidades como padre con el maravilloso hijo que tengo.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Leer el blog

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up

A continuación
Continuous deployment