Come si testa la logica dello stato?

Question

Accepted Answer

Testare la logica dello stato aumenta la fiducia che le transizioni e gli aggiornamenti dello stato siano corretti. La strategia dipende da *come* è strutturata la logica — le funzioni pure (reducer) sono le più facili da testare, quindi uno stato ben architettato è anche uno stato ben testabile.

## Test pure reducer direttamente (il caso più semplice e di maggior valore)

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

Poiché i reducer sono funzioni pure, basta chiamarli con un input e asserire l'output — nessun rendering, nessun mocking, veloce e deterministico. Questo è il *motivo* per cui il pattern pure-reducer è così apprezzato.

## Test dei selettori

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

## Test di hook personalizzati / logica dello 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` ti permettono di testare la logica dello stato di hook/store in isolamento.

## Test dei componenti in base al comportamento, non ai dettagli implementativi

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

Testa quello che l'utente vede/fa (comportamento), non i dettagli implementativi — così i refactor non rompono i test.

## Test dello stato asincrono (mock della rete)

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

Usa MSW o mock per testare in modo deterministico le transizioni loading/success/error.

## Cosa prioritizzare

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

## Perché è importante

I bug dello stato sono tra i più impattanti, quindi testare la logica dello stato è ad alto valore.

Crucialmente, **uno stato ben strutturato è intrinsecamente testabile**: i pure reducer e i selettori sono banali da testare unitariamente (nessun mock, deterministico), il che è un argomento forte per quella architettura.

Sapere come testare i reducer/selettori direttamente, gli hook con `renderHook`, i componenti in base al comportamento visibile all'utente, e i flussi asincroni con reti simulate — evitando test fragili basati sui dettagli implementativi — fornisce una copertura affidabile della logica più probabile che causi bug sottili.