state 로직을 어떻게 테스트하나요?

Question

Accepted Answer

state 로직을 테스트하면 state 전이와 갱신이 올바르다는 확신을 쌓을 수 있습니다. 전략은 로직이 *어떻게* 구조화되었는지에 따라 달라집니다 — 순수 함수(reducer)가 가장 테스트하기 쉬우므로, 잘 설계된 state는 곧 테스트하기 좋은 state입니다.

## 순수 reducer를 직접 테스트(가장 쉽고 가치가 높은 경우)

```js
// reducer는 순수: (state, action) => newState → 테스트가 간단, mock 불필요
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([]); // ✅ 원본이 변경되지 않았는지 확인(immutability)
  });
});
```

reducer는 순수 함수이므로 입력으로 호출하고 출력을 단언하기만 하면 됩니다 — 렌더링도, mocking도 없이 빠르고 결정적입니다. 이것이 바로 순수 reducer 패턴이 그토록 가치 있는 *이유*입니다.

## selector 테스트

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

## 커스텀 hook / store 로직 테스트

```jsx
import { renderHook, act } from "@testing-library/react";

it("increments", () => {
  const { result } = renderHook(() => useCounter());
  act(() => result.current.increment()); // act가 state 갱신을 감쌈
  expect(result.current.count).toBe(1);
});
```

`renderHook` + `act`는 hook/store state 로직을 격리해 테스트하게 해줍니다.

## 컴포넌트는 내부 구현이 아니라 동작으로 테스트

```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(); // 렌더링된 결과를 단언
});
```

사용자가 보고/하는 것(동작)을 테스트하고 구현 세부사항은 테스트하지 마세요 — 그래야 리팩터링이 테스트를 깨뜨리지 않습니다.

## 비동기 state 테스트(네트워크 mock)

```js
// fetch/API를 mock(예: MSW)한 뒤 loading → success/error 전이를 단언
it("handles fetch error → error state", async () => { ... });
```

MSW나 mock을 사용하여 loading/success/error 전이를 결정적으로 테스트하세요.

## 무엇을 우선할까

```text
reducer/selector/순수 로직 → 철저히 단위 테스트(저렴, 가치 높음)
컴포넌트 동작              → 핵심 사용자 흐름을 통합 테스트
비동기 흐름                → mock된 API로 전이 테스트
프레임워크 내부나 사소한 setter는 테스트하지 말 것
```

## 왜 중요한가

state 버그는 가장 영향력 있는 것에 속하므로, state 로직을 테스트하는 것은 가치가 높습니다.

결정적으로, **잘 구조화된 state는 본질적으로 테스트 가능**합니다: 순수 reducer와 selector는 단위 테스트가 간단합니다(mock 불필요, 결정적). 이는 그 아키텍처를 위한 강력한 논거입니다.

reducer/selector를 직접, hook을 `renderHook`으로, 컴포넌트를 사용자에게 보이는 동작으로, 비동기 흐름을 mock된 네트워크로 테스트할 줄 알고 — 깨지기 쉬운 구현 세부사항 테스트를 피하면 — 미묘한 버그를 일으킬 가능성이 가장 높은 로직에 대해 신뢰할 수 있는 커버리지를 얻습니다.