テスト駆動開発（TDD）

概要

最初にテストを書きます。失敗するのを確認します。そして最小限のコードを書いて合格させます。

コア原則： テストが失敗するのを確認しなければ、そのテストが正しいことをテストしているかどうか分かりません。

ルールの文字通りの違反は、ルールの精神の違反です。

使用時期

常に：

• 新機能
• バグ修正
• リファクタリング
• 動作変更

例外（人間パートナーに相談してください）:

• 使い捨てプロトタイプ
• 生成されたコード
• 設定ファイル

「今回だけTDDをスキップしよう」と思いますか？やめてください。それは自己正当化です。

鉄則

失敗するテストなしにプロダクションコードなし

テストの前にコードを書きましたか？削除してください。最初からやり直してください。

例外なし：

• 「参照として保持」しないでください
• テストを書く際に「適応」させないでください
• 見ないでください
• 削除とは削除を意味します

テストから新たに実装してください。以上です。

レッド・グリーン・リファクタリング

digraph tdd_cycle {
    rankdir=LR;
    red [label="RED\nWrite failing

...