Test Basados en Propiedades

Por Carlos Blé Jurado

El pasado viernes 25 de enero de 2020, facilitamos un coding dojo en nuestra oficina como parte de las actividades de la comunidad Agile Canarias. Esta vez, estuvimos practicando Property Based Testing (Test Basados en Propiedades).

La idea es definir unos test donde en lugar de especificar datos concretos de entrada y de salida, le especificamos al framework cuál es el comportamiento esperado de la función que estamos probando y le pedimos que sea la propia herramienta quien genere por nosotros los datos de entrada. Las herramientas de Property Based Testing, generan cientos o miles de casos de prueba por nosotros, probando desde los casos más esperados hasta los más límite.

En cierto modo, es una forma de automatizar la exploración (exploratory testing), ya que automáticamente se generan casos en los que un humano difícilmente hubiera pensado. Desde luego, una persona que programa no suele estar habituada a pensar en casos límite tan rebuscados. No se sustituye la exploración que haría una buena tester, pero sí que es un gran complemento. En las pruebas exploratorias se utiliza la aplicación como “usuario” (un poco malicioso y curioso, eso sí) de manera que necesitamos toda la aplicación, a ser posible, corriendo en un entorno muy parecido al de producción. Sin embargo, las herramientas de test basados en propiedades están orientadas a funciones rápidas que puedan ejecutarse en poco tiempo (idealmente, menos de un segundo), ya que el framework va a lanzar al menos 100 casos diferentes cada vez.

Las funciones que realizan cálculos complejos o que gestionan el estado de la aplicación, son muy buenas candidatas para ser ejercitadas con este tipo de herramientas, ya que se van a encargar de probar la explosión combinatoria si pudiera darse.

Para esta sesión estuvimos trabajando la Maxibón Kata de Karumi, con su repositorio usando Java y JUnitQuickCheck. También estuvimos trabajando la kata en versión Python, con Hypothesis.

La introducción a Hypothesis la hicimos extrayendo parte de un ejercicio de mi reciente libro de TDD, donde explico cómo funciona la herramienta.

Lo que rompió la cabeza a algunos de los particantes del dojo, fue introducir el factor aleatoriedad en los test. La pregunta que surgía era la siguiente: si desconozco qué datos en concreto van a entrar a la función, puesto que son generados por la herramienta, ¿cómo puedo hacer afirmaciones sobre la salida de la función (los asserts)? Bien, el truco está en pensar cuáles son las propiedades invariantes que tiene la función que estamos diseñando y ser capaces de plasmarlas en forma de test. En nuestro ejercicio de la Maxibón Kata, una invariante era que la nevera (estado del sistema) no podía tener nunca menos de dos helados. Así que un test era ese:

1
2
3
4
5
6

@given(lists(DeveloperStrategy), integer())
def test_the_freezer_will_never_be_empty(developers, initial_maxibon_count):
    assume (initial_maxibon_count > 2)
    freezer = Freezer(initial_maxibon_count)
    freezer.give_maxibons_to(developers)
    assert freezer.maxibon_count() >= 2

La primera línea le pide al framework que genere una lista de developers y un entero aleatorio. Este test se va a ejecutar al menos 100 veces (valor por defecto en Hypothesis), con diferentes combinaciones de valores para esos dos parámetros.

Gracias a las reflexiones del grupo tras cada iteración de la kata, descubrimos que como mínimo obtenemos tres beneficios al escribir test basados en propiedades:

• Nos obligan a pensar muy bien en las propiedades (reglas de negocio) que deben cumplir nuestras funciones.
• Los nombres de los test describen esas propiedades, ya no vale con poner nombres de cualquier manera, de tipo “return 4”, porque no manejamos el dato concreto.
• Son un gran complemento para ejercitar el código con valores límite y combinaciones impensables, añadiendo un nivel extra de confianza en nuestro código.

John Hughes, uno de los padres de QuickCheck, narra muy bien en qué consiste la técnica con un ejemplo muy ilustrativo:

En cuanto al funcionamiento de Hypothesis, Matt Bachmann lo cuenta muy bien en esta charla.

Desde ahora estamos empezando a añadir suites de test basados en propiedades en nuestros proyectos como complemento a nuestros test de siempre ¿Y tú, lo vas a probar?