テスト駆動開発

哲学

基本原則: テストは実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証すべきです。コードは完全に変わる可能性がありますが、テストは変わるべきではありません。

良いテストは統合テストスタイルです。公開APIを通じて実際のコードパスを実行します。テストはシステムが 何を するかを記述し、どのように するかは記述しません。良いテストは仕様書のように読めます。「ユーザーは有効なカートでチェックアウトできる」と書けば、どんな機能が存在するかが正確にわかります。これらのテストは内部構造を気にしないため、リファクタリングに耐えられます。

悪いテストは実装に結合しています。内部の協調オブジェクトをモックしたり、プライベートメソッドをテストしたり、外部手段（インターフェースを使わずにデータベースを直接クエリするなど）で検証したりします。警告サイン：リファクタリングするとテストが壊れるのに、振る舞いは変わっていない場合です。内部関数の名前を変えてテストが失敗するなら、それらのテストは振る舞いではなく実装をテストしていたのです。

詳しくはtests.mdの例とmocking.mdのモッキングガイドラインを参照してください。

アンチパターン: 水平スライス

すべてのテストを先に書いてから、すべての実装を書くことはしないでください。 これは「水平スライス」です。REDを「すべてのテストを書く」、GREENを「すべてのコードを書く」として扱っています。

これは質の悪いテストを生み出します：