Fuzz testing: probar propiedades en vez de ejemplos

Hay una asimetría incómoda en las pruebas por ejemplos que rara vez se enuncia en voz alta: los casos que escribes son los que se te ocurren, y los que se te ocurren son los que ya tuviste en la cabeza mientras implementabas. La lista vacía, el cero, el uno, el nombre con acento si eres cuidadoso. La entrada que rompe el código es, por definición, la que no imaginaste, así que la técnica que consiste en imaginar entradas tiene un punto ciego que coincide exactamente con la región donde viven los fallos. El fuzz testing no mejora tu imaginación, la sustituye por una fuente que no tiene prejuicios: un generador que produce valores del tipo que le pidas, incluidos los feos, los enormes, los vacíos y los que contienen caracteres que no sabías que existían. A cambio te pide algo más difícil que escribir un ejemplo: enunciar qué debería ser cierto para todas las entradas. Ese cambio de registro, de la tabla de casos a la propiedad universal, es el verdadero contenido intelectual de la técnica, y su efecto secundario más valioso es que obliga a entender la función mejor de lo que hacía falta para escribirla.

De la tabla de ejemplos a la propiedad universal

Escribir una propiedad exige responder a una pregunta distinta de la habitual. No es qué devuelve la función para esta entrada, sino qué relación se mantiene entre cualquier entrada y su salida. Esa relación suele ser más débil que un valor concreto, y ahí está su fuerza: precisamente por ser débil, puede afirmarse de infinitas entradas. Que ordenar una lista devuelve otra de la misma longitud es una afirmación modesta, pero es cierta siempre, y basta para descubrir una implementación que pierde duplicados. Que invertir dos veces devuelve el original es igual de modesta, y basta para descubrir media docena de errores de índices.

module OrdenTest exposing (suite)

import Expect
import Fuzz exposing (int, list, string)
import Orden exposing (ordenar)
import Test exposing (Test, describe, fuzz, fuzz2)


suite : Test
suite =
    describe "ordenar"
        [ fuzz (list int) "conserva la longitud" <|
            \xs ->
                List.length (ordenar xs)
                    |> Expect.equal (List.length xs)
        , fuzz (list int) "el resultado esta ordenado" <|
            \xs ->
                let
                    ys =
                        ordenar xs
                in
                List.map2 (<=) ys (List.drop 1 ys)
                    |> List.all identity
                    |> Expect.equal True
        , fuzz (list int) "es idempotente" <|
            \xs ->
                ordenar (ordenar xs)
                    |> Expect.equal (ordenar xs)
        , fuzz (list int) "coincide con la implementacion de referencia" <|
            \xs ->
                ordenar xs
                    |> Expect.equal (List.sort xs)
        ]

Un generador también es un valor componible

Fuzz sigue el mismo patrón que el resto de las bibliotecas del ecosistema: unos pocos primitivos y unas operaciones que toman generadores y devuelven generadores. Hay enteros, enteros en rango, flotantes, booleanos, cadenas, listas, arrays, maybes y results, y con eso ya se cubren los tipos de la biblioteca estándar. Lo interesante empieza cuando el tipo es tuyo: entonces se construye el generador con las mismas herramientas que cualquier otra transformación, aplicando un constructor sobre generadores más simples o encadenando cuando la forma de un valor depende de otro.

Este punto merece énfasis porque decide si la técnica se usa de verdad o se abandona a la segunda semana. Un generador restringido a los tipos primitivos solo sirve para probar utilidades genéricas; un generador de tu tipo de dominio sirve para probar tu dominio, que es donde están las reglas que importan. Y como el generador es un valor con nombre, se escribe una vez en un módulo auxiliar de pruebas y se reutiliza en cada suite que lo necesite.

module Generadores exposing (usuario)

import Fuzz exposing (Fuzzer)
import Usuario exposing (Plan(..), Usuario)


plan : Fuzzer Plan
plan =
    Fuzz.oneOf
        [ Fuzz.constant Gratuito
        , Fuzz.map Pago (Fuzz.intRange 1 120)
        , Fuzz.constant Suspendido
        ]


usuario : Fuzzer Usuario
usuario =
    Fuzz.map3 Usuario
        (Fuzz.stringOfLengthBetween 1 40)
        (Fuzz.intRange 18 120)
        plan

La reducción es la mitad del valor

Un generador que encuentra un fallo con una lista de ochenta enteros de siete cifras te ha dado una mala noticia envuelta en ruido inutilizable. Por eso la biblioteca no se limita a informar del contraejemplo que encontró: cuando una propiedad falla, empieza a probar entradas progresivamente más pequeñas y simples que sigan fallando, y reporta la mínima que conservó el fallo. Aquella lista de ochenta elementos se convierte casi siempre en dos, y los enteros de siete cifras en un cero y un uno. El informe deja entonces de ser una anécdota estadística y pasa a ser un caso mínimo reproducible que suele señalar la línea culpable sin depurar.

El corredor imprime además la semilla de la ejecución, y ese detalle es lo que reconcilia la aleatoriedad con la disciplina de la integración continua. Un fallo que aparece una vez de cada quinientas ejecuciones sería insoportable si no se pudiera reproducir; con la semilla se reproduce exactamente. La costumbre sana es fijar la semilla del fallo mientras se investiga, y convertir después el contraejemplo mínimo en una prueba por ejemplos permanente, que documenta el caso concreto y protege contra la regresión aunque el generador no vuelva a visitar esa región.

flowchart TD
P[Propiedad universal] --> G[Generador produce entradas]
G --> V[Se verifica cien veces]
V -->|todas pasan| OK[Propiedad sostenida]
V -->|una falla| S[Reduccion del contraejemplo]
S --> M[Caso minimo con semilla]
M --> T[Prueba por ejemplo permanente]
style G fill:#89b4fa,color:#11111b
style S fill:#f9e2af,color:#11111b
style T fill:#a6e3a1,color:#11111b