Comment testez-vous la logique d'état ?

Question

Accepted Answer

Tester la logique d'état renforce votre confiance que vos transitions et mises à jour d'état sont correctes. La stratégie dépend de *comment* la logique est structurée — les fonctions pures (reducers) sont les plus faciles à tester, donc un état bien architecturé est aussi un état bien testable.

## Test des reducers purs directement (le cas le plus simple et à haut rendement)

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

Puisque les reducers sont des fonctions pures, vous les appelez simplement avec une entrée et affirmez la sortie — pas de rendu, pas de mock, rapide et déterministe. C'est *pourquoi* le pattern du reducer pur est si apprécié.

## Test des selecteurs

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

## Test des hooks personnalisés / logique 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` vous permettent de tester la logique d'état du hook/store en isolation.

## Test des composants par comportement, pas par les internes

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

Testez ce que l'utilisateur voit/fait (comportement), pas les détails d'implémentation — pour que les refactorisations ne cassent pas les tests.

## Test de l'état asynchrone (mocké le réseau)

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

Utilisez MSW ou des mocks pour tester les transitions loading/success/error de manière déterministe.

## Ce qu'il faut prioriser

```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
```

## Pourquoi c'est important

Les bugs d'état figurent parmi les plus impactants, donc tester la logique d'état a une valeur élevée.

De façon cruciale, **un état bien structuré est intrinsèquement testable** : les reducers purs et les selecteurs sont triviaux à tester unitairement (pas de mocks, déterministe), ce qui est un argument solide en faveur de cette architecture.

Savoir tester les reducers/selecteurs directement, les hooks avec `renderHook`, les composants par le comportement visible par l'utilisateur, et les flux asynchrones avec des réseaux mockés — tout en évitant les tests fragiles basés sur les détails d'implémentation — offre une couverture fiable de la logique la plus susceptible de causer des bugs subtils.