個人開発 SaaS のテスト戦略 — 単体 / 統合 / E2E / Visual / 手動の階層配分

この記事は約 4 分で読めます。

筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ

「何を、どの層で、どれだけテストするか」 — 個人開発でも テスト戦略の構造化 で品質が決まります。本記事では、運用中の SaaS 「たすきば Knowledge Relay」 で採用している階層配分を整理します。

サービスの機能紹介・画面イメージ・コンセプトは公式プロダクトページをご覧ください。
👉 たすきば Knowledge Relay — 公式プロダクトページ

テストピラミッド

       /\
      /  \    Manual (リリース前手動 UAT)
     /----\
    / E2E  \  Playwright (主要シナリオ)
   /--------\
  / Visual   \  Playwright Visual Regression
 /------------\
/ Integration  \  Service + Prisma
/----------------\
/ Unit (Vitest)  \  最大数、最速

下層ほど数が多く、上層ほど少ない。下層は速く、上層は遅い。

---

1. 各層の役割

層	数	実行時間	目的
単体テスト (Vitest)	1,500+	30 秒〜2 分	ロジックの正しさ
統合テスト (Vitest + Prisma)	200〜500	1〜5 分	認可 + DB
E2E (Playwright)	50〜100	5〜15 分	フロー全体
Visual Regression	20〜40	数分	UI 崩れ
手動 UAT	主要	1〜数時間	感覚チェック

---

2. 単体テスト — 最大数、最速

test('parsePrice は "1,500円" を 1500 にする', () => {
  expect(parsePrice('1,500円')).toBe(1500);
});

大量に書ける、軽量。

---

3. 統合テスト — 認可とビジネスロジック

test('listProjects は viewerTenantId のプロジェクトだけ返す', async () => {
  const result = await listProjects({ viewerTenantId: 'A' });
  expect(result.every(p => p.tenantId === 'A')).toBe(true);
});

テナント境界 / 認可ロジックの検証はここ。

---

4. E2E テスト — 主要ユーザフロー

test('プロジェクト作成から提案表示まで', async ({ page }) => {
  await page.goto('/projects/new');
  await page.fill('input[name="name"]', 'テストプロジェクト');
  await page.click('button:has-text("作成")');
  await expect(page).toContainText('過去の関連資産');
});

全層を貫くシナリオ、UI 込み。

---

5. どの層に重きを置くか

たすきばは 下層 (単体 + 統合) を厚く する方針。

理由	内容
実行が速い	CI 高速化
バグ再現が容易	個別バグ追跡
リファクタの安全網	大規模変更時

E2E は主要シナリオに絞る。全 page を E2E でカバーする必要はない。

---

6. 認可テストの重点配置

たすきばでは、認可テストを 統合テスト層に集中。

□ viewerTenantId フィルタ動作
□ ロール別の許可 / 拒否
□ super_admin の例外
□ 自己ロール変更禁止

E2E まで上げる必要はない (Service テストで verify できる)。

---

7. テストカバレッジは KPI にしない

カバレッジ % は KPI にしません。

観点	ルール
重要ロジック	必ずテスト
バグ修正	再現テスト必須
認可テスト	網羅

カバレッジを数値で追うと、テストのためのテストが量産される。

---

8. 手動テストの限定

自動化できないものだけ手動テスト。

手動でやる	自動化する
提案エンジンの精度	機能テスト
UI の使い勝手	リグレッション
リリース前総合確認	認可テスト

人間の時間は手動テストに使うものではない。

---

9. E2E のフレーキー対策

E2E は environment-dependent でフレーキーになりがち。

□ 待機ルール統一 (waitForSelector、sleep 禁止)
□ セレクタは data-testid 優先
□ 各テストで独立した DB 状態
□ 並列実行は worker isolation

フレーキーを 1 件発見したら即修正、放置しない。

---

おわりに

層	数	役割
単体テスト	1,500+	ロジック検証
統合テスト	200〜500	認可 + DB
E2E	50〜100	主要シナリオ
Visual Regression	20〜40	UI 崩れ検知
手動 UAT	主要	リリース前総合確認

階層化することで、各層が異なるリスクをカバー します。

本記事のテスト戦略は、運用中の SaaS 「たすきば Knowledge Relay」 で実装しています。
👉 たすきば Knowledge Relay — 公式プロダクトページ