Kuinka testat state-logiikkaa?

Question

Accepted Answer

State-logiikan testaaminen rakentaa luottamusta siihen, että tilasi siirtymät ja päivitykset ovat oikein. Strategia riippuu siitä, *kuinka* logiikka on rakennettu — puhtaat funktiot (reducers) ovat helpoimpia testata, joten hyvin arkkitehtoitu state on myös hyvin testattava state.

## Testaa puhtaat reducers suoraan (helpoin, suurimman arvon tapaus)

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

Koska reducers ovat puhtaita funktioita, kutsut niitä vain syötöllä ja väität tuloksen — ei renderöintiä, ei mocking, nopeaa ja deterministista. Tämä on *miksi* pure-reducer-malli on niin arvostettu.

## Testaa selectors

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

## Testaa custom hooks / store-logiikkaa

```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` antavat sinulle mahdollisuuden testata hook/store state-logiikkaa eristetyssä tilassa.

## Testaa komponentit käyttäytymisen mukaan, ei sisäisesti

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

Testaa mitä käyttäjä näkee/tekee (käyttäytyminen), ei toteutuksen yksityiskohtia — jotta refaktorointi ei riko testeja.

## Testaa async-tilaa (mock verkko)

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

Käytä MSW:ää tai mockeja loading/success/error-siirtymien deterministiseen testaamiseen.

## Mihin keskittyä

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

## Miksi se on tärkeää

State-virheet ovat vaikutuksiltaan suurimpia, joten state-logiikan testaaminen on korkean arvon asia.

Ratkaisevasti, **hyvin strukturoitu state on luontaisesti testattava**: puhtaat reducers ja selectors ovat triviaaleja yksikkötestata (ei mockeja, deterministinen), mikä on vahva argumentti tälle arkkitehtuurille.

Tietää kuinka testata reducers/selectors suoraan, hooks käyttäen `renderHook`, komponentit käyttäjän näkyvän käyttäytymisen mukaan ja async-virrat mockitulla verkolla — samalla kun vältetään hauraita toteutuksen yksityiskohtien testeja — tarjoaa luotettavan kattavuuden logiikalle, joka todennäköisimmin aiheuttaa hienovaraisia virheitä.