Por que TCA es tan testeable

A lo largo de este track has pagado una cuenta larga: reducers que no pueden tocar el mundo, efectos que hay que devolver como valores en vez de simplemente ejecutar, dependencias que se declaran e inyectan en lugar de usarse a mano, navegación modelada como datos, macros y key paths por todas partes. Cada decisión tuvo un coste en ceremonia. Esta lección cobra el pago. Porque las tres primeras —reducer puro, efecto como valor, dependencia controlada— no son tres buenas prácticas independientes: son tres caras de una sola propiedad, el determinismo, y el determinismo es lo que hace que toda la lógica de una app TCA sea verificable con la exactitud que viste en el TestStore. La testeabilidad de TCA no es una característica que alguien añadió; es la sombra inevitable de haberse negado, desde el primer nivel, a mezclar la lógica con el mundo.

Tres pilares, una sola propiedad

La testeabilidad no descansa sobre un truco sino sobre tres decisiones que solo funcionan juntas. Ninguna basta por sí sola: un reducer puro que ejecutara sus efectos al vuelo seguiría siendo intestable, y un efecto como valor que leyera el reloj real seguiría siendo no determinista. Encajadas, las tres cierran todas las fugas de indeterminación.

La pureza aísla la lógica, el efecto como valor vuelve describible lo asíncrono y la dependencia controlada hace el entorno sustituible. Cada pilar tapa una fuente distinta de indeterminación, y solo al taparlas las tres queda algo que se puede afirmar sin ambigüedad.

Un reducer es una función, y las funciones se comparan

Reunidos los tres pilares, un reducer tiene la forma (State, Action, Dependencias) -> (State, Effect). Y como las dependencias se inyectan, en un test las fijas: con ellas clavadas, el reducer se reduce a (State, Action) -> (State, Effect), es decir, una función pura. Testear una función pura es lo más viejo y sencillo del oficio: le das entradas y comparas salidas. Sin mocks de mocks, sin esperas, sin intermitencias.

func reduce(into state: inout State, action: Action) -> Effect<Action> {
  switch action {
  case .incrementar:
    state.cuenta += 1
    return .none
  case .guardarPulsado:
    return .run { [cuenta = state.cuenta] send in
      try await clienteAPI.guardar(cuenta)
      await send(.guardado)
    }
  }
}

La rama pura muta y devuelve .none —un valor—; la rama con efecto devuelve .run, que es una descripción de trabajo, no el trabajo. Ambas ramas son salidas de una función cuyas únicas entradas son state, action y el clienteAPI inyectado. Fija esas tres entradas y las salidas quedan fijas. Esa fijeza es la testeabilidad: no hay nada que dependa del momento, de la máquina ni de la red.

Esa transparencia referencial es lo que el TestStore explota sin más ceremonia: si el estado siguiente es función de las entradas, el diff exhaustivo del nivel anterior tiene siempre una respuesta única y estable que afirmar. Y es la misma propiedad que regala la reproducción de bugs. Como una sesión no es más que una secuencia de acciones aplicadas sobre un estado inicial —y todo eso son valores—, grabar el guion de acciones que condujo a un fallo y volver a pasarlo reproduce el fallo idéntico, sin adivinar y sin no puedo replicarlo en mi máquina. El determinismo no sirve solo para que los tests pasen: sirve para que el pasado se pueda volver a vivir tal cual fue.

flowchart LR
S[State] --> R[Reducer puro]
A[Action] --> R
D[Dependencias inyectadas] --> R
R --> S2[State siguiente]
R --> E[Effect como valor]
E --> A2[Action de vuelta]
A2 --> R
style R fill:#89b4fa,color:#11111b
style D fill:#f9e2af,color:#11111b

Lo que los mocks nunca dieron

El mundo anterior a este enfoque persiguió el mismo objetivo con otras herramientas y nunca llegó del todo. Para testear una clase inyectabas protocolos y escribías implementaciones falsas a mano —una clase mock por colaborador y por test— que se desviaban de la interfaz real en cuanto esta cambiaba. Lo asíncrono se domaba con XCTestExpectation y esperas reales, así que los tests eran lentos e intermitentes. El tiempo se fingía con trucos sobre DispatchQueue que se filtraban entre tests.

// El mundo de antes: un protocolo, un mock a mano y una espera real
protocol ClienteAPI { func cargar() async throws -> [Item] }

final class ClienteAPIMock: ClienteAPI {
  var resultado: [Item] = []
  func cargar() async throws -> [Item] { resultado }
}

func testCarga() {
  let mock = ClienteAPIMock()
  mock.resultado = [.demo]
  let vm = ListaViewModel(cliente: mock)
  let esperada = expectation(description: "carga")
  vm.onCargado = { esperada.fulfill() }
  vm.aparecer()
  wait(for: [esperada], timeout: 1.0)   // espera real: fuente de intermitencia
  XCTAssertEqual(vm.items, [.demo])
}

La raíz del problema no eran las herramientas sino la forma de la cosa a testear: un objeto que hacía cosas, que solo podías observar desde fuera y nunca sostener como un valor. El movimiento de TCA es más profundo que un mejor tooling: cambia esa forma. Lo que está bajo test deja de ser un objeto que ejecuta efectos y pasa a ser una función que devuelve descripciones de efectos.

// El mismo test en TCA: sin protocolo falso, sin mock, sin espera
await store.send(.aparecer) { $0.cargando = true }
await store.receive(\.datosRecibidos) {
  $0.cargando = false
  $0.items = [.demo]
}

Una vez el comportamiento es un valor, no lo simulas con un mock, no esperas a que ocurra, no falsificas el tiempo a su alrededor: le das entradas y comparas salidas. Los mocks eran un parche para una forma que se resistía al test; TCA no mejoró el parche, eliminó la resistencia.

La ceremonia y su dividendo

El coste es real y TCA no lo esconde: macros, key paths, indirección, una curva de aprendizaje empinada. La pregunta honesta no es si hay ceremonia —la hay— sino qué compra. Y compra, pieza por pieza, capacidades de testeo concretas.

• El reducer puro compra la aserción de estado exacta, campo a campo.
• El efecto como valor compra el receive determinista, sin esperas reales.
• La dependencia controlada compra un tiempo, un azar y una red sustituibles.
• La composición de los niveles anteriores compra tests por feature en aislamiento.
• La navegación como datos compra el testing de flujos como simple comparación de valores.