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

Por Qué las Contraseñas Largas son más Seguras que las Complejas

"Tu contraseña debe tener al menos 8 caracteres, una mayúscula, un número y un símbolo…

1 día ago

Gini, KS y AUC: Cómo Medir la Calidad de un Modelo de Credit Scoring

Cuando un analista de riesgo presenta un nuevo scorecard ante el comité de dirección, la…

3 días ago

Curiosidad: De dónde vienen foo, bar y foobar

Si revisáis código o documentación de otros programadores, tarde o temprano os toparéis con dos…

1 semana ago

BG/NBD + Gamma/Gamma: el modelo probabilístico para CLV en compras continuas

Los dos artículos anteriores cubrieron el CLV clásico —una fórmula útil pero que trata a…

1 semana ago

Errores habituales al trabajar con DataFrames grandes en Pandas (y cómo evitarlos)

Hay un momento muy concreto en la vida de casi todo análisis: el código que…

2 semanas ago

Champion vs Challenger: Cómo los Bancos Validan Modelos Nuevos antes de Ponerlos en Producción

Has construido un nuevo modelo de credit scoring. Las métricas de validación son mejores que…

2 semanas ago

This website uses cookies.