Testear update: la transición como afirmación verificable

En una aplicación imperativa, preguntar qué le pasa al estado cuando el usuario pulsa un botón no tiene respuesta local. El estado vive repartido en varios objetos, la pulsación dispara un manejador que llama a un servicio que muta un almacén que notifica a un observador, y para saber el resultado hay que recorrer esa cadena entera con la esperanza de que nadie más la haya tocado por el camino. En esta arquitectura la misma pregunta tiene una respuesta que cabe en una línea, porque existe exactamente una función que la responde y su firma lo dice todo: recibe un mensaje y un modelo, devuelve un modelo y un comando. No hay otra vía por la que el estado pueda cambiar, no hay observadores que se enteren primero, no hay orden de ejecución que negociar. Esa unicidad convierte la prueba de la lógica de estado en el caso más favorable imaginable: se construye el modelo de partida como se construye cualquier registro, se llama a la función con el mensaje que interesa y se compara el resultado con el modelo que la regla de negocio exige. Nada más forma parte del experimento, porque nada más participa en el fenómeno.

La transición como experimento cerrado

Probar la función de actualización no requiere ninguna técnica especial porque es una función corriente. Lo único que conviene establecer pronto es una manera cómoda de fabricar modelos de partida, ya que un modelo real tiene bastantes campos y repetirlos completos en cada caso enterraría la afirmación bajo el ruido. La solución idiomática consiste en definir un modelo base en el fichero de pruebas y modificarlo por campos en cada caso concreto, de forma que lo escrito en cada prueba sea exactamente lo relevante para esa prueba y nada más.

module ContadorTest exposing (suite)

import Contador exposing (Model, Msg(..), update)
import Expect
import Test exposing (Test, describe, test)


base : Model
base =
    { cuenta = 0, limite = 10, bloqueado = False, historial = [] }


aplicar : Msg -> Model -> Model
aplicar msg modelo =
    Tuple.first (update msg modelo)


suite : Test
suite =
    describe "update"
        [ test "incrementar suma uno a la cuenta" <|
            \_ ->
                aplicar Incrementar base
                    |> .cuenta
                    |> Expect.equal 1
        , test "incrementar en el limite no pasa del limite" <|
            \_ ->
                aplicar Incrementar { base | cuenta = 10 }
                    |> .cuenta
                    |> Expect.equal 10
        , test "un contador bloqueado ignora los incrementos" <|
            \_ ->
                aplicar Incrementar { base | bloqueado = True }
                    |> Expect.equal { base | bloqueado = True }
        , test "reiniciar conserva el limite configurado" <|
            \_ ->
                aplicar Reiniciar { base | cuenta = 7, limite = 99 }
                    |> Expect.all
                        [ .cuenta >> Expect.equal 0
                        , .limite >> Expect.equal 99
                        ]
        ]

El comando devuelto y sus dos estrategias

La segunda componente del resultado plantea un problema real: un comando es un tipo opaco cuyo contenido el runtime interpreta, y no admite comparación por igualdad ni inspección. No se puede afirmar que la función devolvió una petición concreta a una dirección concreta, porque desde el código no hay forma de mirar dentro. La primera estrategia, perfectamente legítima y la más común en proyectos pequeños, consiste en aceptar esa limitación y probar únicamente la parte del estado, descartando el comando con el ayudante que toma el primer elemento del par.

La segunda estrategia cambia la firma de la función para que no devuelva un comando sino un valor de un tipo propio que enumera los efectos que la aplicación sabe pedir. La función de actualización pasa a ser una relación entre datos y datos por completo, ese tipo de efectos se traduce a comandos reales en un único punto del programa, y las pruebas recuperan la capacidad de afirmar qué se pidió, con qué argumentos y en qué circunstancias. El coste es una capa de traducción; el beneficio es que la decisión de efectuar algo, que suele ser la parte con reglas de negocio, deja de ser invisible para las pruebas.

type Efecto
    = Ninguno
    | GuardarBorrador String
    | PedirUsuario Int
    | Navegar String


update : Msg -> Model -> ( Model, Efecto )
update msg modelo =
    case msg of
        EscribioTexto texto ->
            if String.length texto > 20 then
                ( { modelo | borrador = texto }, GuardarBorrador texto )

            else
                ( { modelo | borrador = texto }, Ninguno )

        PulsoGuardar ->
            ( { modelo | guardando = True }, GuardarBorrador modelo.borrador )


-- En la prueba, el efecto ya es un valor comparable
test "un borrador largo se guarda solo" <|
    \_ ->
        update (EscribioTexto (String.repeat 30 "a")) base
            |> Tuple.second
            |> Expect.equal (GuardarBorrador (String.repeat 30 "a"))

Secuencias de mensajes y especificación viva

Muchas reglas interesantes no se manifiestan en una transición aislada sino en una sucesión: escribir, borrar, volver a escribir y comprobar que el historial tiene un solo elemento; abrir el diálogo, cancelarlo y verificar que el formulario quedó como estaba. Como la función es pura y devuelve el modelo siguiente, una secuencia se expresa plegando una lista de mensajes sobre el modelo inicial, sin ninguna maquinaria adicional. El recorrido de usuario se convierte así en un dato, y el dato se lee de un vistazo.

recorrido : List Msg -> Model -> Model
recorrido mensajes modelo =
    List.foldl aplicar modelo mensajes


test "cancelar tras editar deja el formulario intacto" <|
    \_ ->
        base
            |> recorrido
                [ AbrirDialogo
                , EscribioTexto "borrador a medias"
                , CancelarDialogo
                ]
            |> Expect.equal base

flowchart LR
M0[Modelo inicial] --> U1[update con Msg uno]
U1 --> M1[Modelo intermedio]
M1 --> U2[update con Msg dos]
U2 --> M2[Modelo final]
M2 --> A[Expect sobre el estado]
U1 --> E[Efecto como dato]
U2 --> E
E --> B[Expect sobre lo solicitado]
style U1 fill:#89b4fa,color:#11111b
style U2 fill:#89b4fa,color:#11111b
style A fill:#a6e3a1,color:#11111b
style B fill:#f9e2af,color:#11111b