テスト駆動開発

哲学

コア原則: テストは実装の詳細ではなく、公開インターフェースを通じて動作を検証すべきです。コードは完全に変わるかもしれません。テストは変わるべきではありません。

優れたテストはインテグレーション的です。公開 API を通じた実際のコードパスを実行します。システムが何をするかを説明し、どのようにするかではありません。優れたテストは仕様書のように読めます。「ユーザーは有効なカートでチェックアウトできる」はどの機能が存在するかを正確に伝えます。これらのテストは内部構造に関心がないため、リファクタリングを乗り越えます。

悪いテストは実装に結合しています。内部のコラボレータをモック化したり、プライベートメソッドをテストしたり、外部手段で検証したり(インターフェースを使う代わりにデータベースを直接クエリするなど)します。警告兆候: リファクタリングでテストが壊れるが、動作は変わっていない。内部関数の名前を変更してテストが失敗する場合、これらのテストは動作ではなく実装をテストしていました。

例は tests.md を、モック化のガイドラインは mocking.md を参照してください。

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

**すべてのテストを先に書いて、その

...