Cum testezi logica de stare?

Question

Accepted Answer

Testarea logicii de stare construiește încredere că tranzițiile de stare și actualizările tale sunt corecte. Strategia depinde de *cum* este structurată logica — funcțiile pure (reducers) sunt cele mai ușoare de testat, deci starea bine arhitectată este și o stare bine testabilă.

## Testează pure reducers direct (cazul cel mai ușor, cu cea mai mare valoare)

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

Deoarece reducers sunt funcții pure, pur și simplu le apelezi cu o intrare și afirmi ieșirea — fără redare, fără mocking, rapid și determinist. Aceasta este *de ce* modelul pure-reducer este atât de valorizat.

## Testează selectori

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

## Testează hook-uri personalizate / logica magazinului

```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` te lasă să testezi logica de stare a hook-ului/magazinului în izolare.

## Testează componente după comportament, nu după internale

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

Testează ceea ce vede/face utilizatorul (comportament), nu detaliile implementării — deci refactoringurile nu sparg testele.

## Testează starea asincronă (mock-ează rețeaua)

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

Folosește MSW sau mock-uri pentru a testa tranzițiile loading/success/error determinist.

## Ce să prioritizezi

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

## De ce este important

Bugurile de stare sunt printre cele mai impactante, deci testarea logicii de stare are valoare ridicată.

Crucial, **starea bine structurată este inerent testabilă**: pure reducers și selectori sunt banali de testat unitar (fără mock-uri, determinist), ceea ce este un argument puternic pentru acea arhitectură.

Știind cum să testezi direct reducers/selectori, hook-uri cu `renderHook`, componente după comportamentul vizibil utilizatorului și fluxuri asincrone cu rețele mock-ate — în timp ce eviti testele fragile ale detaliilor implementării — oferă acoperire fiabilă a logicii care are cea mai mare probabilitate de a provoca bug-uri subtile.