Wie testest du State-Logik?

Question

Accepted Answer

Das Testen von State-Logik schafft Vertrauen darin, dass deine State-Übergänge und Aktualisierungen korrekt sind. Die Strategie hängt davon ab, *wie* die Logik strukturiert ist — reine Funktionen (Reducer) sind am einfachsten zu testen, daher ist gut strukturierter State auch gut testbar.

## Test reine Reducer direkt (der einfachste Fall mit höchster Rentabilität)

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

Da Reducer reine Funktionen sind, rufst du sie einfach mit einer Eingabe auf und überprüfst die Ausgabe — kein Rendering, kein Mocking, schnell und deterministisch. Dies ist *warum* das Pure-Reducer-Muster so geschätzt wird.

## 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-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` ermöglichen es dir, Hook/Store-State-Logik isoliert zu testen.

## Test Komponenten nach Verhalten, nicht nach Implementierungsdetails

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

Teste das, was der Benutzer sieht/macht (Verhalten), nicht Implementierungsdetails — damit Refactorings Tests nicht kaputt machen.

## Test asynchronen State (Mock das Netzwerk)

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

Verwende MSW oder Mocks, um Loading/Success/Error-Übergänge deterministisch zu testen.

## Worauf du dich konzentrieren solltest

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

## Warum es wichtig ist

State-Fehler gehören zu den wirkungsvollsten, daher ist State-Logik-Testing hochwertig.

Entscheidend ist: **Gut strukturierter State ist inhärent testbar**: Reine Reducer und Selectors sind trivial zu Unit-Testen (kein Mocking, deterministisch), was ein starkes Argument für diese Architektur ist.

Zu wissen, wie man Reducer/Selectors direkt testet, Hooks mit `renderHook`, Komponenten nach benutzerverkehrsverhaltenrelevanter Verhalten und Async-Flows mit gemockten Netzwerken — während man fragile Implementation-Detail-Tests vermeidet — liefert zuverlässige Abdeckung der Logik, die am ehesten zu subtilen Fehlern führt.