状態ロジックをテストすることで、状態遷移と更新が正しいことへの信頼が高まります。戦略はどのようにロジックが構造化されているかに依存します — 純粋関数（reducer）は最もテストしやすいため、よく設計された状態は同時にテスト可能な状態でもあります。
純粋reducerを直接テストする（最も簡単で高価値なケース）
(, {
(, {
initial = [];
next = (initial, { : , : { : , : } });
(next).([{ : , : }]);
(initial).([]);
});
});
Reducerは純粋関数であるため、入力を指定して呼び出し、出力をアサートするだけです — レンダリングなし、モッキングなし、高速で決定論的です。これが純粋reducerパターンが非常に評価される理由です。
it("selects the cart total", () => {
const state = { cart: { items: [{ price: 10 }, { price: 5 }] } };
expect(selectCartTotal(state)).toBe(15);
});
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により、フック/ストア状態ロジックを分離してテストできます。
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 fetch/API (e.g. MSW), then assert loading → success/error transitions
it("handles fetch error → error state", async () => { ... });
MSWまたはモックを使用して、loading/success/error遷移を決定論的にテストします。
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
状態バグは最も影響の大きいバグの1つであるため、状態ロジックをテストすることは高い価値があります。
重要なのは、よく構造化された状態は本質的にテスト可能であるということです：純粋reducerとセレクターはユニットテストが簡単です（モックなし、決定論的）。これはそのアーキテクチャの強力な論拠です。
Reducer/セレクターを直接テストする方法、renderHookでフックをテストする方法、ユーザーに見える動作でコンポーネントをテストする方法、そしてモックされたネットワークで非同期フローをテストする方法を知る一方で、脆い実装詳細ベースのテストを避ける — これにより、微妙なバグを引き起こしそうなロジックに対する信頼できるカバレッジが得られます。