Hvordan tester du state logic?

Question

IT Interview Practice · Accepted Answer

Testing av state logic bygger tillit til at state transitions og updates dine er korrekte. Strategien avhenger av *hvordan* logikken er strukturert — pure functions (reducers) er enklest å teste, så vel-arkitekturert state er også vel-testbar state.

## Test pure reducers direkte (det enkleste, høyeste-verdi tilfellet)

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

Fordi reducers er pure functions, kaller du dem ganske enkelt med en input og asserterer outputen — ingen rendering, ingen mocking, rask og deterministisk. Dette er *hvorfor* pure-reducer-mønsteret er så verdsatt.

## Test selectors

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

## Test custom hooks / store logic

```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` lar deg teste hook/store state logic isolert.

## Test components by behavior, not internals

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

Test hva brukeren ser/gjør (behavior), ikke implementeringsdetaljer — så refactors bryter ikke tester.

## Test async state (mock the network)

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

Bruk MSW eller mocks for å teste loading/success/error transitions deterministisk.

## What to prioritize

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

## Hvorfor det er viktig

State bugs er blant de mest impactfulle, så testing av state logic er høy-verdi.

Kritisk er det at **vel-strukturert state er iboende testbar**: pure reducers og selectors er trivielle å unit teste (ingen mocks, deterministisk), som er et sterkt argument for den arkitekturen.

Å vite hvordan du tester reducers/selectors direkte, hooks med `renderHook`, components ved bruker-synlig behavior, og async flows med mockede nettverk — mens du unngår skjøre implementation-detail tester — gir pålitelig dekning av logikken som mest sannsynlig forårsaker subtile bugs.

Test pure reducers direkte (det enkleste, høyeste-verdi tilfellet)

Test selectors

Test custom hooks / store logic

Test components by behavior, not internals

Test async state (mock the network)

What to prioritize

Hvorfor det er viktig

Relaterte spørsmål