tdd

tdd — テスト駆動開発の動作プロトコル

運用上の不変条件

• 公開シームのみ：公開モジュールインターフェイスを通じて、観測可能な動作のみをテストします。プライベートなヘルパーメソッドや内部状態変数に対するアサーションは行いません。
• 失敗するアサーションは1つ（RED）：本番コードに手を加える前に、受け入れ基準を表す失敗テストをちょうど1つ作成します。テストを実行し、構文エラーやインポートエラーではなく、想定したアサーションエラーで失敗することを確認します。
• 最小限の実装（GREEN）：失敗テストを成功させるために必要な最小限の本番コードのみを記述します。先を見越した機能、先行的な抽象化、未テストのコード分岐は禁止します。
• アサーションの当てずっぽうを排除：具体的な状態遷移、戻り値のペイロード、またはドメインの不変条件に対してアサーションを行います。浅い存在確認のアサーション（expect(res).toBeDefined()、assert len(x) > 0）は禁止します。
• 正規の出力契約：(設計上省略 — これはモデルが呼び出す動作プロトコルです。その出力は、本番コードとテストスイートの差分です。)

ドメインの評価基準

1. レッド・グリーン・リファクターサイクル

1. RED：具体的な受け入れ基準を捉えたテストケースを1つ作成します。テストランナーを実行し、RED状態であることを確認します。
2. GREEN：テストを通すための最小限のロジックを実装します。テストランナーと型チェッカーを実行し、GREEN状態であることを確認します。
3. REFACTOR：テストが成功した状態を保ちながら、冗長な変数を削除し、重複ロジックを取り除き、ドメインの用語に沿った命名に整えます。

2. 不変条件とプロパティのチェック

浅い例示テストよりも、不変条件のテストを優先します。

• 有界性：任意の入力に対して範囲の境界が保たれる必要があります（0 <= discount <= total）。
• 冪等性：同じ変更を再適用しても、結果の状態は変わりません。
• 往復性：ドメインエンティティをシリアライズしてからデシリアライズしても、深い等価性が保たれます。

よくないパターンと改善策

// Smell: Testing private internals (Couples test to implementation)
expect(service['internalCache'].has('item-123')).toBe(true);

// Remedy: Testing through public observable seam
const result = await service.fetchItem('item-123');
expect(result.id).toBe('item-123');

# Smell: Shallow assertion roulette (Passes even if data is corrupt)
assert response.status_code == 200
assert response.json() is not None

# Remedy: Concrete invariant assertion
assert response.status_code == 200
data = response.json()
assert data["order_id"] == expected_id
assert data["status"] == "CONFIRMED"