¿Cómo pruebas la lógica de estado?

Question

Accepted Answer

Probar la lógica de estado genera confianza en que tus transiciones de estado y actualizaciones sean correctas. La estrategia depende de *cómo* esté estructurada la lógica — las funciones puras (reducers) son las más fáciles de probar, por lo que el estado bien arquitectado también es un estado bien testeable.

## Prueba los reducers puros directamente (el caso más fácil y de mayor valor)

```js
// reducers are pure: (state, action) => newState → trivial to test, no mocks
describe("todosReducer", () => {
  it("adds a todo", () => {
    const initial = [];
    const next = todosReducer(initial, { type: "todos/added", payload: { id: 1, text: "A" } });
    expect(next).toEqual([{ id: 1, text: "A" }]);
    expect(initial).toEqual([]); // ✅ verify the original wasn't mutated (immutability)
  });
});
```

Como los reducers son funciones puras, simplemente los llamas con una entrada y afirmas la salida — sin renderizado, sin mocking, rápido y determinista. Esta es la *razón* por la que el patrón pure-reducer es tan valorado.

## Prueba los selectores

```js
it("selects the cart total", () => {
  const state = { cart: { items: [{ price: 10 }, { price: 5 }] } };
  expect(selectCartTotal(state)).toBe(15);
});
```

## Prueba los hooks personalizados / lógica del store

```jsx
import { renderHook, act } from "@testing-library/react";

it("increments", () => {
  const { result } = renderHook(() => useCounter());
  act(() => result.current.increment()); // act wraps state updates
  expect(result.current.count).toBe(1);
});
```

`renderHook` + `act` te permiten probar la lógica de estado de hook/store de forma aislada.

## Prueba los componentes por comportamiento, no por internos

```jsx
import { render, screen, fireEvent } from "@testing-library/react";

it("shows the count after clicking", () => {
  render(<Counter />);
  fireEvent.click(screen.getByRole("button"));
  expect(screen.getByText("1")).toBeInTheDocument(); // assert the rendered RESULT
});
```

Prueba lo que el usuario ve/hace (comportamiento), no detalles de implementación — así los refactores no rompen las pruebas.

## Prueba el estado asincrónico (simula la red)

```js
// mock fetch/API (e.g. MSW), then assert loading → success/error transitions
it("handles fetch error → error state", async () => { ... });
```

Usa MSW o mocks para probar las transiciones loading/success/error de forma determinista.

## Qué priorizar

```text
Reducers/selectors/pure logic → unit test thoroughly (cheap, high value)
Component behavior           → integration test key user flows
Async flows                  → test transitions with mocked APIs
Don't test framework internals or trivial setters
```

## Por qué es importante

Los errores de estado están entre los más impactantes, por lo que probar la lógica de estado es de alto valor.

De forma crucial, **el estado bien estructurado es inherentemente testeable**: los reducers y selectores puros son triviales de probar en unidad (sin mocks, determinista), lo que es un argumento fuerte para esa arquitectura.

Saber probar reducers/selectores directamente, hooks con `renderHook`, componentes por comportamiento visible para el usuario y flujos asincrónico con redes simuladas — mientras evitas pruebas frágiles de detalles de implementación — brinda una cobertura confiable de la lógica más propensa a causar errores sutiles.