Pruebas automáticas en R con testthat (Creación de paquetes en R 3ª parte)

Seguimos con nuestra serie en la que explicamos cómo crear un paquete R en la que se realizará una introducción a las pruebas automáticas. Incluir pruebas automáticas en nuestro código es clave para poder mantener a medida que crece. Las pruebas no solo permiten garantizar que el código funciona correctamente hoy en día, sino que permite garantizar que continuará funcionando correctamente en un futuro. Avisandonos de error que se pueden en el futuro debido a cambios en otros paquetes de los que dependamos o del propio R. La forma más fácil de escribir pruebas automáticas en R es con el paquete testthat.

El paquete testthat

En primer lugar, necesitamos instalar el paquete testthat para poder escribir y ejecutar pruebas automáticas. Un paquete que se puede instalar desde el CRAN simplemente escribiendo:

install.packages("testthat")

Creación de la estructura de pruebas

Las pruebas automáticas se guardan en la carpeta test de proyecto, una carpeta que no ha creado el asistente de RStudio. Pero esto no es un problema porque esta se puede crear automáticamente con devtools. La primera vez que lanzamos el comando devtools::test(), con el que habitualmente se lanzaran las pruebas unitarias, nos preguntará si deseamos crear la infraestructura para las pruebas. Al contestar de forma afirmativa creará la carpeta tests, encontrando en el interior de esta carpeta encontraremos un archivo testthat.R y una carpeta testthat. El archivo R es el que se encarga de cargar los paquetes necesario y lanzar las pruebas, pruebas que se almacenarán en la carpeta testthat.

Creación de una función para probar

En primer lugar, para nuestro paquete podemos crear una función básica que sume dos números. Función que se debe guardar en un archivo en la carpeta R. Para nuestro ejemplo vamos la siguiente función en el archivo suma.R.

suma <- function(a,b) {
  return(a + b)
}

Además de ello también podemos borrar el archivo hello.R creado por el asistente de RStudio, el cual no necesitamos.

Probar el comportamiento de la función suma

Para probar el código es necesario crear un archivo R cuyo nombre comience por test dentro de la carpeta tests/testthat. Es importante que el archivo comienza por test, ya que sino no se ejecutarán las pruebas de este. En nuestro ejemplo crearemos un archivo testSuma.R en el que incluirá el siguiente código:

context("Suma")

test_that("Suma", {
  expect_equal(suma(1, 1), 2)
  expect_equal(suma(1, 2), 3)
})

En la primera línea, con la función context() se indica el contexto en el que ejecutan las pruebas, algo clave para identificar rápidamente donde se produce los fallos. Posteriormente se utiliza la función test_that() para definir un conjunto de pruebas con un nombre, nombre que se pasa como primer parámetro de la función. Como segundo parámetro se pasa el código que ha de ejecutar y las valores que se espera obtener.

En el ejemplo las operaciones son bastante sencillas, simplemente se comprueba si la función suma para los valores 1 y 1 da como resultado 2 y si para 1 y 2 da como resultado 3. Lo que se esperaría de una función suma.

Ahora solamente se tiene que escribir devtools::test() para comprobar que nuestro código pasa las pruebas. Lo que, si todo está bien, nos debería indicar que el código ha pasado dos pruebas positivamente y no se han producido ni fallos ni warnings.

Tolerancia en las comprobaciones

Siempre que se trabaja con número reales es necesario tener en cuenta una cierta tolerancia, ya que pequeños errores numéricos pueden dar al traste las comprobaciones. Por eso las funciones de expectación de testthat incluye por defecto un grado de tolerancia. En el caso de que necesitemos aumentar el grado de tolerancia se puede usar la propiedad tolerance para modificar el valor. Por ejemplo, la siguiente comparación es válida ya que la diferencia entre los dos valores está por debajo de 1e-4.

expect_equal(1, 1.00001, tolerance=1e-4)

Conclusiones

En esta entrada se ha visto cómo crear pruebas automáticas en R con testthat e incluirlas en nuestro paquete. Pruebas que nos garantizan el correcto funcionamiento del código hoy y en un futuro indicando cuando una tarea de mantenimiento o una dependencia externa cambia el comportamiento de la librería. La próxima semana continuaremos con pruebas automáticas más avanzadas.

Imagen de Peter H en Pixabay

Publicidad