Jak testować logikę stanu (state)?

Question

IT Interview Practice · Accepted Answer

Testowanie logiki stanu buduje pewność, że twoje przejścia stanów i aktualizacje są poprawne. Strategia zależy od *tego, jak* logika jest zstrukturyzowana — czyste funkcje (reducers) są najłatwiejsze do testowania, więc dobrze zaprojektowany stan jest również dobrze testowalnym stanem.

## Testuj czyste reducers bezpośrednio (najłatwiejszy, najcenniejszy przypadek)

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

Ponieważ reducers są czystymi funkcjami, po prostu je wywołujesz z wejściem i asercisz wyjście — bez renderowania, bez mockowania, szybko i deterministycznie. To jest *dlaczego* wzorzec pure-reducer jest tak ceniony.

## Testuj selektory

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

## Testuj niestandardowe hooki / logikę magazynu

```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` pozwalają ci testować logikę stanu hooka/magazynu w izolacji.

## Testuj komponenty na podstawie zachowania, a nie implementacji

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

Testuj to, co widzi/robi użytkownik (zachowanie), a nie szczegóły implementacji — więc refaktoring nie łamie testów.

## Testuj asynchroniczny stan (mockuj sieć)

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

Wykorz MSW lub mocki, aby testować przejścia loading/success/error deterministycznie.

## Dlaczego to ważne

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

## Dlaczego to ważne

Błędy stanu są jednymi z najbardziej wpływowych, więc testowanie logiki stanu ma wysoką wartość.

Koniecznie, **dobrze zstrukturowany stan jest z natury testowalny**: czyste reducers i selektory są banalne do unit testowania (bez mocków, deterministycznie), co jest mocnym argumentem dla tej architektury.

Wiedzenie, jak testować reducers/selectors bezpośrednio, hooki z `renderHook`, komponenty na podstawie zachowania widocznego dla użytkownika i asynchroniczne przepływy z mockowanymi sieciami — jednocześnie unikając kruchy testów szczegółów implementacji — daje niezawodne pokrycie logiki, która najprawdopodobniej powoduje subtelne błędy.

Testuj czyste reducers bezpośrednio (najłatwiejszy, najcenniejszy przypadek)

Testuj selektory

Testuj niestandardowe hooki / logikę magazynu

Testuj komponenty na podstawie zachowania, a nie implementacji

Testuj asynchroniczny stan (mockuj sieć)

Dlaczego to ważne

Dlaczego to ważne

Powiązane pytania