Qué es el TestStore

Un test corriente pregunta; el TestStore exige. La diferencia parece de matiz y es de género. Cuando escribes una prueba normal eliges un puñado de propiedades observables, las miras después de ejecutar algo y decides si te convencen: el test cubre aquello que su autor recordó mirar y guarda un silencio cómplice sobre todo lo demás. El TestStore invierte la carga de la prueba. No te deja observar, te obliga a declarar de antemano el estado exacto que esperas; luego ejecuta el reducer de verdad y compara, campo a campo, lo que dijiste contra lo que ocurrió. Si algo se movió sin que lo anunciaras, falla. Si un efecto devolvió una acción que no reclamaste, falla. Si al acabar queda una tarea viva, falla. Esta lección monta el aparato desde cero y defiende una tesis incómoda: esa severidad no es un rasgo de carácter del framework, sino la única forma conocida de que un test que pasa signifique algo más que la ausencia de sospecha.

Un store construido para desconfiar

Un TestStore se construye con las mismas dos piezas que el store de producción —un estado inicial y el reducer que lo gobierna— más una tercera opcional que en la práctica nunca lo es: el bloque donde sustituyes las dependencias por versiones controladas.

@Test
func minimo() async {
  let store = TestStore(initialState: Contador.State()) {
    Contador()
  } withDependencies: {
    $0.uuid = .incrementing
  }

  await store.send(.incrementar) {
    $0.cuenta = 1
  }
}

Por dentro no hay magia, hay contabilidad. El TestStore mantiene dos representaciones del mundo: el estado real, que sólo el reducer muta, y el estado esperado, que sólo tú mutas dentro de la closure de aserción. Cada send ejecuta el reducer auténtico —no un doble, no un simulacro— sobre el estado real, aplica tu closure sobre una copia del estado anterior y compara los dos resultados con Equatable. Si difieren, el fallo no dice «algo salió mal»: imprime un diff estructural con la línea exacta que sobra y la que falta. A esa contabilidad de estado se le suma una segunda, la de las acciones que los efectos devuelven, que se encolan en vez de aplicarse a escondidas y quedan esperando a que las reclames.

De ahí se sigue la diferencia esencial con el Store de producción, que ejecuta y sigue adelante. El store real es un motor; el TestStore es un motor con un notario al lado que levanta acta de cada movimiento y compara el acta con la declaración que firmaste antes de arrancar. Esa asimetría explica por qué el TestStore vive en el módulo de tests y por qué su API es más estrecha y más ceremoniosa: no está hecho para hacer funcionar una app, sino para no dejar pasar ni un gesto sin registrar.

El fallo que produce esa comparación merece mirarse de cerca, porque no es un booleano rojo sino un documento:

// Lo que imprime el TestStore cuando la prediccion no encaja
//
//   A state change does not match expectation:
//
//         Contador.State(
//           cuenta: 1,
//     −     ultimoToque: nil
//     +     ultimoToque: Date(2026-07-30T10:00:00Z)
//         )
//
//   (Expected: −, Actual: +)

El diff es estructural y mínimo: no vuelca los dos estados enteros sino la diferencia entre ellos, línea a línea, con el signo menos marcando lo que declaraste y el más lo que de verdad ocurrió. En un estado con cuarenta campos anidados eso es la distancia entre un mensaje inútil y un diagnóstico: el TestStore no te dice que algo no cuadra, te señala el campo exacto, dentro de qué estructura hija y con qué valor concreto. Esa legibilidad no es cosmética, es lo que hace sostenible la exigencia; una comparación exhaustiva que fallara con un volcado ilegible sería insoportable a la tercera prueba.

Las cuatro deudas que cobra al final

Las dos primeras filas son simétricas y esa simetría no es adorno: la regla exacta es que hay closure de aserción si y sólo si hubo mutación, porque una aserción redundante miente sobre el comportamiento tanto como una omitida. Las dos siguientes se comprueban tarde, cuando el store se destruye al final del ámbito de la prueba, y por eso su mensaje aparece a veces desconectado de la línea que lo causó: es el precio de vigilar el ciclo de vida completo y no sólo cada paso aislado. La última es la única que puede fallar en mitad de la ejecución sin que nada haya salido mal del todo; es, de hecho, una alarma de diseño disfrazada de fallo de test.

La condición que hace posible tanta exigencia

Conviene preguntarse por qué esta clase de instrumento no existe en las arquitecturas de interfaz habituales, y la respuesta es que allí no habría nada que declarar. Sólo puedes afirmar el estado exacto siguiente si ese estado es una función determinista del estado anterior, la acción y las dependencias. Sólo puedes esperar un efecto si el efecto es un valor devuelto y no una llamada disparada a ciegas dentro del método. Sólo puedes congelar el tiempo si el reloj entró por una dependencia en lugar de estar cableado en una llamada estática. El TestStore no inventa esas propiedades: las cobra.

// La ceremonia de los niveles previos es la precondición del test
@Reducer
struct Feature {
  @Dependency(\.clienteAPI) var clienteAPI     // sustituible
  @Dependency(\.continuousClock) var reloj     // congelable

  var body: some ReducerOf<Self> {
    Reduce { state, action in                  // puro: estado y accion adentro
      switch action {
      case .aparecer:
        state.cargando = true
        return .run { send in                  // el efecto es un valor
          await send(.datos(try await clienteAPI.cargar()))
        }
      case let .datos(items):
        state.cargando = false
        state.items = items
        return .none
      }
    }
  }
}

Merece la pena hacer el ejercicio inverso y romper una a una esas precondiciones para ver qué se pierde. Si el reducer llamara a Date() directamente en vez de recibir la fecha por dependencia, la aserción sobre ese campo sería imposible de escribir: el valor esperado cambiaría en cada ejecución y sólo cabría afirmar algo vago sobre él. Si el efecto fuese una llamada disparada dentro del case en lugar de un valor devuelto, no habría cola que reclamar ni forma de saber si se disparó una vez o dos. Y si el estado fuese una clase con referencias compartidas, la copia previa que la closure recibe no sería una copia sino un alias del estado real, y la comparación daría siempre verde porque estarías comparando un valor consigo mismo. Cada exigencia del TestStore es la contrapartida de una libertad que renunciaste a tomarte niveles atrás.

flowchart TD
S[send de una accion] --> R[Reducer real muta el estado real]
S --> D[Closure declara el estado esperado]
R --> C[Comparacion campo a campo]
D --> C
R --> Q[Acciones de efectos a la cola]
Q --> RC[receive las reclama una a una]
RC --> C
C --> F[Fin de la prueba: cola vacia y sin efectos vivos]
style C fill:#f9e2af,color:#11111b
style F fill:#a6e3a1,color:#11111b