Как вы тестируете логику состояния?

Question

Accepted Answer

Тестирование логики состояния (state logic) создает уверенность в том, что ваши переходы состояния и обновления работают правильно. Стратегия зависит от *того, как* структурирована логика — чистые функции (reducers) проще всего тестировать, поэтому хорошо спроектированное состояние также легко тестируемо.

## Тестируйте чистые reducers напрямую (самый простой и ценный случай)

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

Поскольку reducers — это чистые функции, вы просто вызываете их с входными данными и проверяете вывод — никакой визуализации, никаких mock-объектов, быстро и детерминированно. Именно *поэтому* паттерн pure-reducer так ценится.

## Тестируйте селекторы

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

## Тестируйте пользовательские hooks / логику хранилища

```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` позволяют вам тестировать логику состояния hook-а/хранилища в изоляции.

## Тестируйте компоненты по поведению, а не по внутренней реализации

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

Тестируйте то, что видит/делает пользователь (поведение), а не детали реализации — поэтому рефакторинг не сломает тесты.

## Тестируйте асинхронное состояние (mock-ируйте сеть)

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

Используйте MSW или mock-объекты для детерминированного тестирования переходов loading/success/error.

## Почему это важно

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

## Почему это важно

Ошибки в состоянии наиболее значительны, поэтому тестирование логики состояния имеет высокую ценность.

Критически важно, что **хорошо спроектированное состояние по своей природе тестируемо**: чистые reducers и селекторы тривиальны для unit-тестирования (без mock-объектов, детерминировано), что является сильным аргументом в пользу этой архитектуры.

Знание того, как тестировать reducers/селекторы напрямую, hooks с `renderHook`, компоненты по видимому пользователю поведению и асинхронные потоки с mock-ированными сетями — при этом избегая хрупких тестов деталей реализации — обеспечивает надежное покрытие логики, которая чаще всего вызывает тонкие ошибки.