tdd

テスト駆動開発

基本ルール

縦方向のレッド・グリーン・リファクタリングのサイクルで進めます。

1. RED：観察可能な振る舞いを1つ検証するテストを1つ書きます。
2. GREEN：そのテストを通すために必要な最小限の本番コードの変更を実装します。
3. REFACTOR：テストがすべて通っている間に限り、コードを整理します。

実装前に、想定したテストをまとめて書いてはいけません。新しいテストは、それまでのサイクルで実際の振る舞いやインターフェースについて得た知見に応じて追加します。

Plaited のデフォルト

• 対象を絞ったテストには bun test を、型チェックには bun --bun tsc --noEmit を使用します。
• it ではなく test を使い、describe で整理します。
• モックよりも、実際の依存関係と実際の実行時境界を優先します。
• リモート API、時刻、乱数、まれなファイルシステムのケースなど、外部との境界に限ってモックを使います。
• 条件分岐に依存するアサーションは避けます。まず分岐を検証し、その後で分岐ごとの値を検証します。
• 条件分岐、フォールバック、エラー経路の両方をテストします。
• プライベートなヘルパーではなく、パブリックインターフェースと実行時の契約をテストします。
• 変更対象に適用されるリポジトリのスキルと AGENTS.md のルールに従います。

作業を始めるとき

まずコードベースを調べます。パブリックインターフェース、期待される振る舞い、リスクの境界をコード、テスト、ドキュメントから確認できる場合は、ユーザーに尋ねず、その根拠を使います。

判断材料が見つからず、妥当な仮定を置くにはリスクが高い場合に限り、簡潔な質問を1つだけします。推奨する回答も添えます。

本番コードを書く前に、以下を明確にします。

• テスト対象のパブリックインターフェースまたは実行時境界
• 最初に証明する観察可能な振る舞い
• このサイクルで実行する対象を絞ったテストコマンド
• 引き渡し前に必要な、より広範な検証

サイクルの進め方

振る舞いごとに、以下を行います。

1. 焦点を絞ったテストを1つだけ追加または更新します。
2. 対象を絞ったテストを実行し、意図した理由で失敗することを確認します。
3. テストを通すために必要な最小限のコードだけを実装します。
4. 同じ対象テストを実行し、成功することを確認します。
5. 必要であればリファクタリングし、影響を受けるテストを再実行します。

本番コードを変更する前にテストが通る場合、それは有効な RED の判定ではありません。テストをより厳密にするか、別の振る舞いを選ぶか、既存のテストでその振る舞いがすでに証明されている理由を説明します。

参考ファイル

• references/tests.md：振る舞いテストの例と、実装詳細に依存したテストの注意点
• references/mocking.md：境界に限定したモックのガイダンス
• references/interface-design.md：テスト可能なパブリックインターフェースの設計
• references/deep-modules.md：小さなインターフェースと、内部に機能を持たせる実装のガイダンス
• references/refactoring.md：テストが通った後に実行するリファクタリングの確認事項