Kako testirate logiko stanja?

Question

Accepted Answer

Testiranje logike stanja vam daje zaupanje, da so vaši prehodi stanja in posodobitve pravilni. Strategija je odvisna od *kako* je logika strukturirana — čiste funkcije (reducerji) so najlažje za testiranje, zato je dobro arhitektuirano stanje tudi dobro testabilno stanje.

## Neposredno testirajte čiste reducerje (najlažji, največje vrednosti primer)

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

Ker so reducerji čiste funkcije, jih samo pokličete z vnosom in potrdite izhod — brez renderiranja, brez mockanja, hitro in deterministično. To je *razlog*, zakaj je vzorec čistega reducerja tako cenjen.

## Testirajte selectorje

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

## Testirajte custom hooks / store logiko

```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` vam omogočata testiranje hook/store logike stanja v izolaciji.

## Testirajte komponente po obnašanju, ne po notranjostih

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

Testirajte tisto, kar uporabnik vidi/počne (obnašanje), ne podrobnosti implementacije — tako da refaktoriranje ne prekine testov.

## Testirajte asinkrono stanje (mockajte omrežje)

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

Za testiranje determinističnih prehodov stanja nalaganja/uspeha/napake uporabite MSW ali mockanje.

## Kaj je vredno prednostnega obravnavanja

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

## Zakaj je to wichtig

Napake stanja so med najbolj vplivnimi, zato je testiranje logike stanja visoko vrednostno.

Klučno je, da je **dobro strukturirano stanje naslednje testabilno**: čisti reducerji in selectorji so trivialni za enote testiranje (brez mockanja, deterministično), kar je mocna predlog za to arhitekturo.

Znanje za neposredno testiranje reducerjev/selectorjev, hookov z `renderHook`, komponent po vidnemu vedenju uporabnika in asinkronih tokov z mockiranimi omrežji — medtem ko se izogibate krhkim testom podrobnosti implementacije — vam daje zanesljivo pokritost logike, ki je najbolj verjetna, da povzroči subtilne napake.