Hogyan tesztelted az állapot logikáját?

Question

Accepted Answer

Az állapotlogika tesztelése megbízhatóságot épít azzal kapcsolatban, hogy az állapotátmenetek és frissítések helyesek. A stratégia attól függ, *hogyan* strukturálódik a logika — a tiszta függvények (reducerek) a legkönnyebben tesztelhetők, így a jól felépített állapot egyben jól tesztelhető állapot is.

## Tiszta reducerek közvetlen tesztelése (a legkönnyebb, legmagasabb értékű eset)

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

Mivel a reducerek tiszta függvények, egyszerűen meghívod őket bemeneti értékkel, és kimeneti értéket ellenőrzöl — nincs renderelés, nincs mockingolás, gyors és determinisztikus. Ez az *oka* annak, hogy a tiszta reducer minta annyira értékelt.

## Szelektor tesztelése

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

## Egyéni hookok / tár logika tesztelése

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

A `renderHook` + `act` segítségével elkülönítve tesztelhetod a hookenként/tárolóként az állapotlogikát.

## Komponensek tesztelése viselkedés alapján, nem belső működés alapján

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

Teszteld azt, amit a felhasználó lát/tesz (viselkedés), ne az implementációs részleteket — hogy az átszervezések ne szújasák meg a teszteket.

## Aszinkron állapot tesztelése (mockingolj a hálózatot)

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

Az MSW vagy mockingolások segítségével teszteld a betöltés/siker/hiba átmeneteket determinisztikusan.

## Mit kell előtérbe helyezni

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

## Miért fontos

Az állapot hibái a leghatásosabbak közé tartoznak, ezért az állapot logika tesztelése nagy értékű.

Döntően **a jól strukturált állapot eredendően tesztelhető**: a tiszta reducerek és szelektor egység tesztelése triviális (nincs mockingolás, determinisztikus), amely erős érv a felépítés mellett.

A reducerek/szelektor közvetlen tesztelésének ismerete, a `renderHook`-os hookok, a felhasználó által látható viselkedés alapján történő komponens tesztelés, valamint a mockolásolt hálózattal történő aszinkron folyamatok — miközben elkerülöd a fragilisnek számító implementációs részletekre épülő teszteket — megbízható lefedettséget ad azon logikáról, amely a legvalószínűbben okoz finom hibákat.