テストの観点

このガイドの設計方針は、テストの書きやすさにも影響します。

テストしやすい設計は、良い設計であることが多いです。 逆に、テストが書きにくいと感じたら、設計を見直すサインかもしれません。

---

テストコードの比較

同じ「ユーザー登録」機能でも、設計によってテストの複雑さが変わります。

典型的な設計のテスト

def test_ユーザー登録フロー():
    # Step 1: 入力画面を開く
    response = client.get('/users/new')
    assert response.status_code == 200

    # Step 2: 確認画面へ POST（セッションに保存される）
    response = client.post('/users/new/confirm', data={
        'name': '田中太郎',
        'email': 'tanaka@example.com'
    })

    # Step 3: 確認画面を表示（セッションから読み込み）
    response = client.get('/users/new/confirm')
    assert '田中太郎' in response.text

    # Step 4: 登録実行
    response = client.post('/users/new/submit')

    # Step 5: 完了画面
    response = client.get('/users/new/complete')
    assert '登録が完了しました' in response.text

    # アサーション
    assert User.query.count() == 1

5ステップ、セッション状態に依存、途中で失敗すると原因特定が難しいです。

再設計後のテスト

def test_ユーザーを登録できる():
    response = client.post('/users', data={
        'name': '田中太郎',
        'email': 'tanaka@example.com'
    })

    assert response.status_code == 201
    assert User.query.count() == 1

1ステップ、セッション不要、失敗しても原因が明確です。

---

なぜテストが複雑になるか

設計の特徴	テストへの影響
セッションを使う	セッション状態の組み合わせをテストする必要がある
画面遷移が多い	E2E テストのステップが増える
ルートが多い	テストすべきエンドポイントが増える
確認画面がある	「戻る」「進む」のパターンをテストする必要がある

画面が増えれば、テストも増えます。セッションを使えば、状態の組み合わせが増えます。

---

好循環と悪循環

好循環

テストがある
    ↓
安心して変更できる
    ↓
シンプルな設計に改善できる
    ↓
テストがさらに書きやすくなる
    ↓
（繰り返し）

悪循環

テストがない
    ↓
変更が怖い
    ↓
複雑なまま放置
    ↓
さらにテストが書きにくくなる
    ↓
（繰り返し）

この悪循環を断ち切るには、まず小さなテストを書くことから始めましょう。

---

テストが複雑になったら

テストを書いていて「面倒だな」と感じたら、それは設計を見直すサインかもしれません。

チェックポイント

• テストのセットアップが長い → 依存関係が多すぎないか
• テストのステップが多い → 画面遷移が多すぎないか
• セッションのモックが必要 → セッションを使わない設計にできないか
• 状態の組み合わせが多い → 状態を減らせないか

問いかけ

テストを書く前に、こう問いかけてみる：

• 「このテストは何ステップで書けるか？」
• 「セッションやモックは必要か？」
• 「1つのテストで1つのことを確認できているか？」

---

設計とテストの関係

このガイドの設計方針に従うと、テストも自然とシンプルになる傾向があります。

このガイドの方針	テストへの効果
確認画面を減らす	セッションテストが不要になる
登録画面を統合する	テストすべき画面が減る
編集画面を統合する	似たテストの重複が減る
モードレスを優先する	状態の組み合わせが減る

良い設計はテストしやすく、テストしやすい設計は良い設計です。 この循環を意識すると、設計の質が自然と上がっていきます。

---

補足

テストは「品質を保証するもの」であると同時に、「設計の良し悪しを教えてくれるもの」でもあります。

テストが書きにくいと感じたら、テストの書き方を工夫する前に、設計を見直してみる価値があるかもしれません。