テスト駆動開発(TDD)では、顧客の分析された顧客の要求仕様をテストケースとして初期段階に完成させますが、 開発者やAIがこのテストケースを変更してしまってはTDDの意味がありません。

本稿では、Pythonの pytest を使ってテストを書いている中で、顧客レビュー済みのスペックテスト（仕様テスト）を開発者が変更してしまうのを防ぐためのアイデアをご紹介いたします。

1. テストケースの分類

テストを目的や意図ごとに分類し、テストケース名やディレクトリ構造、マーカーなどを用いて区別する方法がおすすめです。

a. スペックテスト (Specification Tests)

• 目的: 顧客がレビューし、承認した要件や仕様を検証するテスト。
• 特徴: 変更が原則禁止。顧客に影響を与える動作を担保する重要なテスト。
• 例: test_spec_*.py やディレクトリ tests/specifications/ に保存。
• 管理方法:
  • テスト関数に@pytest.mark.specificationを付与。
  • Pull Requestでspecificationマーカー付きのテストが変更された場合にアラートを表示する。

b. 内部テスト / 実装テスト (Implementation Tests)

• 目的: 内部ロジックや具体的なコードの実装を検証。
• 特徴: 開発の進捗やリファクタリングに伴い変更される可能性がある。
• 例: test_impl_*.py やディレクトリ tests/implementation/ に保存。

c. 回帰テスト (Regression Tests)

• 目的: 過去に発生したバグを再現しないことを検証。
• 特徴: 必要に応じて追加・更新するが、元の問題を再発させないために厳格に維持する。

2. 分類の実装例

a. ディレクトリ構造を使う

テストファイルをフォルダごとに分け、役割を明示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

tests/
├── specifications/       # 顧客レビュー済みテスト
│   ├── test_login.py
│   ├── test_user_registration.py
├── implementation/       # 実装テスト
│   ├── test_helpers.py
│   ├── test_internal_logic.py
├── regression/           # 回帰テスト
│   ├── test_bug_1234.py
│   ├── test_issue_5678.py

b. pytestマーカーを使う

pytest.ini にマーカーを定義します。

1
2
3
4
5

[pytest]
markers =
    specification: Tests that verify customer-reviewed specifications
    implementation: Tests for internal logic and implementation
    regression: Tests to ensure bugs do not reappear

テストにマーカーを追加：

1
2
3
4
5
6
7
8
9

import pytest

@pytest.mark.specification
def test_customer_approved_behavior():
    assert some_function() == expected_value

@pytest.mark.implementation
def test_internal_logic():
    assert helper_function() == internal_value

c. テスト変更時のアラートを追加

CI/CDツールでマーカー付きテストが変更されるとアラートを出すルールを設定します。

• 例: GitHub Actionsでpytest --markersを実行して差分をチェック。

3. 開発者への教育とルールの明確化

AI向けの取り組み

• システムプロンプト化:
  • スペックテストを管理するためのルールをシステムプロンプトに記載。

人間向けの取り組み

• コードレビュー:

  • スペックテストに変更が加えられていないか手動でチェック。
  • 必要に応じて、仕様変更プロセスを説明し、開発者にルールの遵守を促す。

• 教育:

  • スペックテストの重要性を伝えるための定期的なワークショップを開催。
  • 新規開発者向けにスペックテスト管理のトレーニングを実施。

4. CI/CDでのガードルール

スペックテスト変更の検知とブロック

顧客レビュー済みのスペックテストが変更された場合、PRをブロックする仕組みを導入します。

例: GitHub Actionsの設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

name: Check Specification Tests

on:
  pull_request:

jobs:
  check_spec_tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Detect changes in specification tests
        run: |
          git diff --name-only origin/main HEAD | grep '^tests/specifications/' && echo "Specification tests have been modified!" && exit 1 || echo "No changes in specification tests."

pytest のディレクトリ構造やマーカーを活用して、スペックテスト（顧客承認済み）と実装テストを分類し、それを開発者に伝える、AIのシステムメッセージに含むことでルールを明確化できます。 また、CI/CDツールでスペックテスト変更を防ぐ仕組みを組み合わせることで、プロジェクトの信頼性を高めることが可能です。