Hur testar du tillståndslogik?

Question

Accepted Answer

Testning av tillståndslogik bygger förtroende för att dina tillståndsövergångar och uppdateringar är korrekta. Strategin beror på *hur* logiken är strukturerad — rena funktioner (reducers) är enklast att testa, så väl arkitekturerad tillståndskod är också väl testbar tillståndskod.

## Testa rena reducers direkt (det enklaste, högvärdesfallet)

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

Eftersom reducers är rena funktioner, anropar du dem helt enkelt med en inmatning och gör en assertion på utmatningen — ingen rendering, ingen mocking, snabbt och deterministiskt. Det är *därför* det rena reducer-mönstret är så värderat.

## Testa selektorer

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

## Testa anpassade hooks / butikslogik

```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` låter dig testa hook/butikslogik isolerat.

## Testa komponenter efter beteende, inte implementeringsdetaljer

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

Testa det användaren ser/gör (beteende), inte implementeringsdetaljer — så omfaktoriseringar bryter inte testen.

## Testa asynkront tillstånd (mocka nätverket)

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

Använd MSW eller mockar för att testa loading/success/error-övergångar deterministiskt.

## Vad du bör prioritera

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

## Varför det spelar roll

Tillståndsfel är bland de mest impactfulla, så testning av tillståndslogik är högvärdig.

Oentligt, **väl strukturerat tillstånd är i sig testbart**: rena reducers och selektorer är triviala att enhetstesta (ingen mockning, deterministiskt), vilket är ett starkt argument för denna arkitektur.

Att veta hur man testar reducers/selektorer direkt, hooks med `renderHook`, komponenter efter användarsynligt beteende och asynkrona flöden med mockade nätverk — samtidigt som du undviker skörande implementeringsdetaljtester — ger tillförlitlig täckning av den logik som sannolikt orsakar subtila buggar.