Kaip testuoti būsenos logiką?

Question

Accepted Answer

Būsenos logikos testavimas suteikia pasitikėjimą, kad jūsų būsenos perėjimai ir atnaujinimai yra teisingi. Strategija priklauso nuo *kaip* yra sustruktūrinta logika — grynos funkcijos (reduktoriai) yra lengviausia testuoti, todėl gerai suprojektuota būsena taip pat yra gerai testuojama būsena.

## Testuokite grynuosius reduktorius tiesiogiai (lengviausias, didžiausios vertės atvejis)

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

Kadangi reduktoriai yra grynos funkcijos, jūs tiesiog juos iškviečiate su įvestimi ir tvirtinate išvestį — jokios renderavimo, jokio suklastojimo, greita ir deterministinė. Tai yra *priežastis*, kodėl grynojo reduktoriaus šablonas yra toks vertinamas.

## Testuokite selektorius

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

## Testuokite pasirinktines funkcijas / saugyklos logiką

```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` leidžia jums testuoti kabliuko/saugyklos būsenos logiką izoliuotai.

## Testuokite komponentus pagal elgesį, o ne detales

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

Testuokite tai, ką vartotojas mato/daro (elgesis), o ne įgyvendinimo detales — kad refaktoringai nesugestų testus.

## Testuokite asinchroninę būseną (suklastokite tinklą)

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

Naudokite MSW arba suklastojimus, norėdami testuoti įkėlimo/sėkmės/klaidos perėjimus deterministiškai.

## Ką pirma priimti

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

## Kodėl tai svarbu

Būsenos klaidos yra viena iš prie pat ryto skleidžiamų klaidų, todėl būsenos logikos testavimas yra didelio svarbos.

Krucialiai, **gerai struktūrizuota būsena yra iš prigimties testuojama**: grynai reduktoriai ir selektoriai yra trivialūs vieneto testams (jokių suklastojimų, deterministinė), o tai yra stipri argumentų priežastis tokiai architektūrai.

Žinant testuoti reduktorius/selektorius tiesiogiai, funkcijas su `renderHook`, komponentus pagal matomą vartotojo elgesį ir asinchroninius srautus su suklastotais tinklais — tuo tarpu vengiant trapių implementacijos detalės testų — suteikia patikimą logikos padengimą, kuris greičiausiai sukels subtilias klaidas.