Testear la vista y los decodificadores: los dos bordes del programa

Los dos bordes de una aplicación tienen mala reputación en materia de pruebas, y en la mayoría de los ecosistemas está justificada. Probar la interfaz suele significar arrancar un navegador de verdad, esperar a que aparezcan elementos, luchar con esperas que fallan una vez de cada treinta y mantener una batería tan lenta que nadie la ejecuta antes de subir código. Probar la deserialización suele significar comprobar que una biblioteca de anotaciones hace lo que promete, ejercicio de escaso interés. En Elm ninguna de las dos cosas es así, y el motivo es el mismo en ambos casos: los dos bordes están hechos de datos. La vista es una función pura que devuelve una descripción del árbol, no una pantalla pintada, de modo que se puede llamar y examinar su resultado como se examina cualquier estructura. Un decodificador es un valor que describe un plan, y ejecutarlo sobre un texto devuelve un resultado que puede ser correcto o erróneo, de modo que la prueba consiste en ejecutar el plan contra un documento real y mirar qué salió. En ninguno de los dos casos hace falta un navegador, un servidor ni una espera.

La vista es un valor consultable

La función de vista devuelve un Html msg, que no es una pantalla sino la descripción de una. Sobre esa descripción se puede lanzar una consulta, buscar un nodo por etiqueta, clase, texto o atributo, y afirmar lo que corresponda. El módulo de consultas trabaja con dos operaciones básicas, encontrar un nodo único o recoger todos los que casan, y con expectativas que comprueban si el nodo tiene ciertas características o cuántos elementos contiene la colección hallada.

Conviene fijar desde el principio el criterio sobre qué afirmar. Una prueba que verifica clases de maquetación, orden de contenedores o profundidad del anidamiento se rompe con cada retoque visual sin haber detectado nunca un fallo real. Una prueba que verifica que un modelo con la lista vacía produce el mensaje de estado vacío, o que un modelo con un error muestra el texto del error, comprueba una decisión de producto y sobrevive a cualquier rediseño. La regla práctica es afirmar sobre lo que el usuario percibe y sobre las bifurcaciones de la vista, nunca sobre su estructura interna.

module VistaTest exposing (suite)

import Html.Attributes as A
import Lista exposing (view)
import Test exposing (Test, describe, test)
import Test.Html.Query as Query
import Test.Html.Selector exposing (attribute, class, tag, text)


suite : Test
suite =
    describe "view"
        [ test "sin elementos muestra el estado vacio" <|
            \_ ->
                view { items = [], cargando = False, error = Nothing }
                    |> Query.fromHtml
                    |> Query.has [ text "Todavia no hay nada aqui" ]
        , test "pinta una fila por elemento" <|
            \_ ->
                view { items = [ "uno", "dos", "tres" ], cargando = False, error = Nothing }
                    |> Query.fromHtml
                    |> Query.findAll [ tag "li" ]
                    |> Query.count (\n -> Expect.equal 3 n)
        , test "mientras carga desactiva el boton" <|
            \_ ->
                view { items = [], cargando = True, error = Nothing }
                    |> Query.fromHtml
                    |> Query.find [ tag "button" ]
                    |> Query.has [ attribute (A.disabled True) ]
        ]

El programa entero como sujeto

Consultar la vista comprueba que un modelo produce cierta pantalla, y probar la actualización comprueba que un mensaje produce cierto modelo, pero entre ambas cosas queda un hueco: que el botón que se ve emita el mensaje que corresponde y que la pantalla resultante sea la esperada. elm-program-test cubre ese hueco tratando el programa completo como sujeto y ofreciendo operaciones escritas en el vocabulario del usuario, no en el del código: pulsar un botón identificado por su texto, rellenar un campo identificado por su etiqueta, y afirmar qué se ve después.

La pieza que hace todo esto viable es la simulación de efectos, y aquí se recoge el fruto de haber modelado los efectos como datos. Si la función de actualización devuelve un valor de un tipo propio, la biblioteca puede traducirlo a un efecto simulado, interceptar la petición de red y dejar que la prueba decida qué responde el servidor. La prueba se convierte entonces en un guion completo con su bifurcación de fallo, sin servidor, sin espera y sin intermitencia.

inicio : ProgramTest Model Msg Efecto
inicio =
    ProgramTest.createElement
        { init = Pagina.init
        , update = Pagina.update
        , view = Pagina.view
        }
        |> ProgramTest.withSimulatedEffects Pagina.simular
        |> ProgramTest.start ()


test "guardar un nombre valido muestra la confirmacion" <|
    \_ ->
        inicio
            |> ProgramTest.fillIn "nombre" "Nombre completo" "Ada Lovelace"
            |> ProgramTest.clickButton "Guardar"
            |> ProgramTest.simulateHttpOk
                "POST"
                "https://api.example.com/usuarios"
                "{ \"id\": 7 }"
            |> ProgramTest.expectViewHas [ text "Guardado correctamente" ]

Los decodificadores contra documentos reales

Un decodificador es una función pura de texto a resultado, así que su prueba es un caso particular de lo que ya sabes hacer. Lo que decide su valor no es la técnica sino la procedencia del documento con el que se prueba: si el JSON de la prueba lo escribiste tú mirando tu propio tipo, la prueba solo demuestra que sabes copiar, y pasará en verde el día en que el servicio cambie un campo. La prueba útil usa una respuesta capturada del servicio real, guardada literalmente, con sus campos sobrantes, sus nulos y sus nombres tal como llegan.

Conviene además probar los documentos que deben fallar. Un decodificador que acepta lo que debería rechazar es un fallo más grave que uno que rechaza de más, porque el primero deja entrar datos mal formados hasta el fondo de la aplicación y el segundo se manifiesta en la frontera con un error legible.

respuestaReal : String
respuestaReal =
    """
    { "id": 42
    , "nombre": "Ada"
    , "plan": "pago"
    , "meses": 12
    , "metadatos": { "creado": "2024-03-01", "origen": "web" }
    }
    """


suite : Test
suite =
    describe "usuarioDecoder"
        [ test "decodifica una respuesta real del servicio" <|
            \_ ->
                Decode.decodeString Usuario.decoder respuestaReal
                    |> Expect.equal
                        (Ok { id = 42, nombre = "Ada", plan = Pago 12 })
        , test "rechaza un plan desconocido" <|
            \_ ->
                Decode.decodeString Usuario.decoder """{ "id": 1, "nombre": "X", "plan": "vitalicio" }"""
                    |> Expect.err
        , fuzz Generadores.usuario "codificar y decodificar devuelve el original" <|
            \u ->
                Encode.encode 0 (Usuario.encoder u)
                    |> Decode.decodeString Usuario.decoder
                    |> Expect.equal (Ok u)
        ]

flowchart TD
J[JSON real capturado] --> D[Decoder ejecutado]
D --> R[Result con valor o error]
R --> A1[Expect sobre el dominio]
M[Model] --> V[view devuelve un arbol]
V --> Q[Query con selectores]
Q --> A2[Expect sobre lo visible]
P[ProgramTest] --> V
P --> D
P --> A3[Recorrido de usuario completo]
style D fill:#89b4fa,color:#11111b
style V fill:#cba6f7,color:#11111b
style P fill:#f9e2af,color:#11111b