UI テスト 30 本を書いてわかった「壊れないアプリ」の作り方

（＊この記事と同様の記事をZennにも投稿しています。）

Vitest + Testing Library 実践記

Game Progress Tracker では UI テストを 30 本以上 書きました。

個人開発でここまでやるのは珍しいですが、結論としては大成功でした。

参考までにアプリの仕様とテスト仕様の一致確認のため、要件定義書とテスト仕様メモ、テストコード一式を置いておきます。

要件定義書：https://github.com/koyanagi-dev/game-progress-tracker-v1/blob/main/docs/requirements/requirements-v0.5.md

テスト仕様メモ：https://github.com/koyanagi-dev/game-progress-tracker-v1/blob/main/docs/tests/test-spec-v0.3.md

テストコード：https://github.com/koyanagi-dev/game-progress-tracker-v1/tree/main/src/tests

---

🎯 UIテストを書く目的

• リファクタリングを安心してできる
• バグの早期発見ができる
• 仕様の曖昧さを無くせる

---

🧪 実際に書いたテストの例

test("undo restores deleted task", async () => {
  render(<App />);
  await userEvent.type(screen.getByPlaceholderText("Add task"), "Slay the Dragon");
  await userEvent.click(screen.getByText("Add"));

  await userEvent.click(screen.getByLabelText("delete-task"));
  await userEvent.click(screen.getByText("Undo"));

  expect(screen.getByText("Slay the Dragon")).toBeInTheDocument();
});

---

🧠 学び

• UIテストは“ユーザー目線の設計”を強制してくれる
• 仕様が自然と明確になる
• バグの温床になりやすい部分が把握できる

---

📌 まとめ

• 少ない工数で大きなリターンがある
• 個人開発こそ UIテストを導入すべき
• 次回の本命プロダクトでも必ず採用する

UIテストは“安心してコードを書き続けるための武器”でした。