Integración con el store real: verificar el bucle completo

Puedes tener reducers impecables, selectores memoizados con precisión quirúrgica y thunks que manejan todos los caminos de error, y aun así entregar una pantalla rota. Basta con que un componente lea el selector equivocado, que despache una acción que ningún reducer maneja, que el middleware que necesitabas no esté registrado o que el estado inicial precargado no tenga la forma que la interfaz espera. Ninguno de los tests anteriores puede detectar esa clase de fallo, porque todos verifican piezas en aislamiento y el defecto vive en las juntas. El test de integración con store real existe exactamente para eso: montar el componente de verdad, dentro del Provider de verdad, con un store construido con tus reducers de verdad, y recorrer el bucle completo del flujo unidireccional —el usuario actúa, se despacha una acción, el reducer produce un estado nuevo, el selector deriva, la interfaz se repinta— afirmando únicamente sobre lo que aparece en pantalla.

El bucle que solo este test recorre

Conviene ver con precisión qué añade este nivel. Los tests anteriores cubren cada arista del diagrama por separado; el de integración cubre el ciclo entero y, sobre todo, cubre el cableado: qué componente consume qué selector, qué acción emite cada interacción, qué middleware está montado en este store concreto.

flowchart LR
A[usuario hace clic] --> B[componente despacha accion]
B --> C[middleware]
C --> D[reducer produce estado nuevo]
D --> E[selector deriva]
E --> F[componente se repinta]
F --> G[afirmacion sobre lo visible]
style A fill:#fab387,color:#11111b
style G fill:#a6e3a1,color:#11111b

Vale la pena nombrar los defectos que solo aquí aparecen, porque justifican el coste. Un componente que consume un selector obsoleto tras un renombrado; una acción despachada con el nombre correcto pero manejada por el slice equivocado; un middleware olvidado al reorganizar configureStore; un preloadedState que la interfaz interpreta de otra forma; un componente memoizado que deja de repintarse porque un selector perdió su estabilidad referencial. Los cinco pasan las pruebas unitarias con nota y rompen la pantalla.

La regla que gobierna todo el diseño de estos tests se enuncia en una línea: se actúa como el usuario y se afirma como el usuario. Se hace clic en un botón identificado por su rol y su nombre accesible, se escribe en un campo por su etiqueta, y se comprueba que aparece un texto. En ningún momento se llama a store.dispatch para preparar la escena ni se consulta store.getState() para verificar el resultado; si haces eso, has escrito un test de thunk con un componente pegado encima y has perdido justo la garantía que buscabas.

renderWithProviders y el aislamiento por test

La pieza de infraestructura es una función de render propia que envuelve el componente en los proveedores que la aplicación necesita y devuelve además el store para los casos límite en que hace falta. Lo esencial es que el store se crea dentro de la función, una vez por invocación: un store de módulo compartido filtra estado entre casos y produce la clase de intermitencia que depende del orden de ejecución, el defecto más caro de diagnosticar de una suite.

import { render } from '@testing-library/react'
import type { RenderOptions } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import { Provider } from 'react-redux'
import { setupStore } from '../store'
import type { AppStore, RootState } from '../store'

interface Opciones extends Omit<RenderOptions, 'queries'> {
  preloadedState?: Partial<RootState>
  store?: AppStore
}

export function renderWithProviders(
  ui: React.ReactElement,
  { preloadedState = {}, store = setupStore(preloadedState), ...resto }: Opciones = {},
) {
  const Envoltorio = ({ children }: { children: React.ReactNode }) => (
    <Provider store={store}>{children}</Provider>
  )
  return { store, usuario: userEvent.setup(), ...render(ui, { wrapper: Envoltorio, ...resto }) }
}

La función setupStore es la misma que usa la aplicación en producción, parametrizada con preloadedState. Ese detalle importa más de lo que parece: si el test construyera su store con una configuración distinta —sin un middleware, con reducers recortados— estaría verificando un sistema que no es el tuyo. El objetivo es que la única diferencia entre el store del test y el de producción sea el estado inicial.

Sobre preloadedState conviene fijar una disciplina, porque es a la vez el atajo legítimo y una puerta trasera. Tiparlo como parcial del RootState permite precargar solo la rama que el flujo necesita, lo cual mantiene los tests legibles; pero un estado precargado que describe una situación inalcanzable —una lista de identificadores sin entidades, una bandera de error junto a datos cargados— produce tests que verifican ficción y que pasan mientras el flujo real falla. Cuando dudes de si un estado es alcanzable, constrúyelo despachando acciones sobre el store y pásalo luego; el reducer es el mejor validador de plausibilidad que tienes.

import { screen } from '@testing-library/react'
import { renderWithProviders } from '../test/utils'
import { ListaTareas } from './ListaTareas'

it('marca una tarea como hecha al hacer clic', async () => {
  const { usuario } = renderWithProviders(<ListaTareas />, {
    preloadedState: {
      todos: { entidades: { a1: { id: 'a1', texto: 'leer', hecho: false } }, ids: ['a1'], filtro: 'todos' },
    },
  })
  await usuario.click(screen.getByRole('checkbox', { name: /leer/i }))
  expect(screen.getByRole('checkbox', { name: /leer/i })).toBeChecked()
})

Asincronía, precisión y coste

Cuando el componente carga datos, este test se combina con la lección anterior: msw responde y la interfaz espera. La regla es no esperar tiempos sino condiciones. Las consultas de la familia find devuelven una promesa que se resuelve cuando el elemento aparece, y waitFor cubre las afirmaciones que no se expresan como presencia de un elemento. Cualquier espera fija por milisegundos es una intermitencia esperando a ocurrir en una máquina de integración continua más lenta que tu portátil.

it('muestra los usuarios que llegan del servidor', async () => {
  renderWithProviders(<PanelUsuarios />)
  expect(screen.getByRole('status', { name: /cargando/i })).toBeInTheDocument()
  expect(await screen.findByText('Ada')).toBeInTheDocument()
  expect(screen.queryByRole('status', { name: /cargando/i })).not.toBeInTheDocument()
})

Ese test recorre las tres capas de una sola vez: el estado de carga que produce la acción pending, la respuesta simulada por msw, la acción fulfilled, el reducer, el selector y el repintado. Es la verificación más parecida a la experiencia real del usuario que puedes obtener sin arrancar un navegador completo, y por eso concentra más confianza por test que cualquier otro nivel.

Queda un caso que la gente resuelve mal por costumbre: los flujos que dependen de un middleware propio. Un listener que reacciona a una acción para lanzar otra, o una saga que coordina dos peticiones, no se prueban espiando lo que emiten sino comprobando su consecuencia visible en la interfaz, exactamente igual que un thunk. La ventaja de que el store del test sea el real es precisamente esa: el middleware está montado, corre de verdad, y si alguien lo desregistra por accidente al reorganizar la configuración del store, este test se pone rojo mientras ninguna prueba unitaria se entera.