R

Medir la cobertura de las pruebas automáticas (Creación de paquetes en R 5ª parte)

Un dato importante a la hora de trabajar con pruebas automáticas es saber que parte del código está cubierto y qué parte no. Ya que las parte que no esté cubierto por pruebas automáticas es más probable que aparezcan fallos durante las tareas de mantenimiento, o que tenga errores porque nunca se hubiese probado esa parte. Para esto en R también tenemos herramientas con las que medir la cobertura de las pruebas automáticas, entre las que podemos destacar el paquete covr.

Esta entrada forma parte de la serie “Creación de paquetes en R” cuyo código se puede encontrar en el repositorio y consta de las siguientes ocho entradas:

  1. Creación de paquetes en R
  2. El archivo DESCRIPTION
  3. Pruebas automáticas con testthat
  4. Pruebas avanzadas con testthat
  5. Medir la cobertura de las automáticas unitarias
  6. Documentación de los paquetes
  7. Creación de vignette
  8. Validación y distribución de los paquetes

Instalación del paquete covr

El paquete covr se puede instalar desde el CRAN de forma estándar, para lo que solamente deberemos escribir en una sesión de R el siguiente comando

install.packages("covr")

Comprobar el grado de cobertura con covr

Para comprobar el grado de cobertura de nuestro código solo es necesario importar el paquete covr y ejecutar el comando package_coverage() en nuestro proyecto.

> library(covr)
> package_coverage()
rlane Coverage: 100.00%
R/suma.R: 100.00%

La respuesta del comando package_coverage() es clara. En la primera línea se nos indica el grado de cobertura del paquete. En nuestro caso son buenas noticias ya que tenemos una cobertura del 100%, es decir, todas las líneas de código han sido probadas al menos una vez. Además, también se puede ver el grado de cobertura de cada uno de los archivos, aunque en nuestro proyecto solo hay uno de momento.

Código sin cobertura

En este punto vamos a crear una nueva función para ver como nos indicaría que tenemos código sin cobertura. Para lo que vamos a crear la función resta y la vamos a almacenar en un nuevo archivo resta.R.

resta <- function(a,b) {
  return(a-b)
}

Si se vuelve a ejecutar el comando una vez se ha creado la nueva función nos encontramos que el grado de cobertura ha bajado del 100% al 50%.

> package_coverage()
rlane Coverage: 50.00%
R/resta.R: 0.00%
R/suma.R: 100.00%

Aunque también tenemos una buena noticia, solamente hay un archivo que no tienen cobertura resta.R.

Informe gráfico de cobertura

El informe de cobertura también se puede ver de forma gráfica, para lo que únicamente se debería guardar la salida del comando package_coverage() en una variable y usar report(). Así para ver el informe gráfico solo deberíamos escribir:

> covr <- package_coverage()
> report(covr)

Lo que nos daría un informe como el que se muestra en la siguiente captura de pantalla.

También se puede ver cada una de las líneas de los archivos. Por ejemplo, en la siguiente captura de pantalla se puede ver que la línea de la función suma se llama dos veces durante las pruebas.

Integración con devtools

Los informes de covr se pueden lanzar desde devtools, lo que facilita introducir esta fase en nuestro flujo de trabajo. Para ello solamente se debería de lanzar las siguientes instrucciones desde la línea de comandos.

devtools::test_coverage()

Conclusiones

En esta entrada de la serie se ha visto cómo medir el grado de cobertura de las pruebas automáticas. Una tarea que nos ayuda cuando el tamaño de nuestro paquete crece, ya que nos informa de parte de código sobre el que no existe cobertura. En la próxima entrega veremos cómo incluir documentación en los paquetes de R.

Imagen de Peter H en Pixabay

¿Te ha parecido de utilidad el contenido?

Daniel Rodríguez

Share
Published by
Daniel Rodríguez
Tags: Unit testing

Recent Posts

Docker Compose: el día a día. Cómo ver qué funciona y qué no

Si acabas de montar tu aplicación en Docker Compose, la primera pregunta que haces cada…

14 horas ago

Migrar tslane a un paquete dual CommonJS y ESM con tsup y Vitest

tslane es la plantilla que uso como punto de partida para mis librerías TypeScript, nacida…

6 días ago

Cómo construir tu primer scorecard paso a paso

En los artículos anteriores de esta serie vimos la teoría detrás del credit scoring: qué…

1 semana ago

Actualizar expresslanets a ES Modules con tsx y Vitest

expresslanets es la plantilla de API REST con Express y TypeScript que empezó como una…

2 semanas ago

Pareto/NBD: cuando el abandono silencioso cambia el CLV

En el artículo del Dashboard vimos que Pareto/NBD aparecía junto a BG/NBD con un ajuste…

2 semanas ago

Por qué migrar tus proyectos TypeScript a ES Modules en 2026

Durante años, CommonJS (require/module.exports) ha sido la forma por defecto de organizar módulos en Node.js,…

3 semanas ago

This website uses cookies.