Como você testa a lógica de estado?

Question

Accepted Answer

Testar a lógica de estado constrói confiança de que suas transições de estado e atualizações estão corretas. A estratégia depende de *como* a lógica é estruturada — funções puras (reducers) são as mais fáceis de testar, portanto, o estado bem arquitetado também é um estado bem testável.

## Teste pure reducers diretamente (o caso mais fácil e de maior 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 reducers são funções puras, você simplesmente os chama com uma entrada e afirma a saída — sem renderização, sem mocking, rápido e determinístico. Esta é a *razão* pela qual o padrão pure-reducer é tão valorizado.

## Teste seletores

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

## Teste custom hooks / lógica de 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` permitem que você teste a lógica de estado do hook/store isoladamente.

## Teste componentes por comportamento, não por internals

```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
});
```

Teste o que o usuário vê/faz (comportamento), não detalhes de implementação — portanto, refatorações não quebram testes.

## Teste estado assíncrono (mock da rede)

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

Use MSW ou mocks para testar transições loading/success/error deterministicamente.

## O que 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 que isso importa

Bugs de estado estão entre os mais impactantes, então testar a lógica de estado é de alto valor.

Crucialmente, **estado bem estruturado é inerentemente testável**: pure reducers e seletores são triviais para testar unitariamente (sem mocks, determinístico), o que é um argumento forte para essa arquitetura.

Saber testar reducers/seletores diretamente, hooks com `renderHook`, componentes por comportamento visível ao usuário e fluxos assíncrônos com redes mockadas — enquanto evita testes frágeis de detalhes de implementação — oferece cobertura confiável da lógica mais provável de causar bugs sutis.