TDDのゴールデンルールは次のように述べています。テストに失敗せずに新しい機能を記述しないでください。
このルールに従わない場合は、TDDを部分的に実行しています（アプリケーション内の複数のクラスに対してのみ単体テストを作成するなど）。これは何もないよりはましです（少なくとも、これらのクラスが必要なことを実行することは知っていますが、アプリケーションの他の部分が機能していて、これらのクラスをそれらと統合できるかどうかはわかりません）が、アプリケーションが期待どおりに機能することを保証するものではありません。したがって、各機能は、アプリケーションの設計をガイドし、アプリケーションの動作（外部ループ）を定義する、失敗した受け入れテストを作成することから始める必要があります。このテストは失敗しますが、この機能はアプリケーションによって実装されていません。次に、この機能（内部ループ）に関係する個別のユニットの単体テストを作成する必要があります。外側のループは、この機能に関係するすべてのクラスが期待どおりに連携していることを確認します。内側のループは、各クラスがそれ自体で期待どおりに機能することを確認します。
すばらしい本からの次の写真成長するオブジェクト指向ソフトウェア、テストによって導かれるは、TDDのこれらの2つのフィードバックループを示しています。
そして、あなたの質問に対する答えは「はい」です。TDDには統合テストが含まれています。これが、TDDの黄金律を破らない唯一の方法です。
AFAIK、TDDは元々、単体テストと統合テストを区別していませんでした。統合テストは、セットアップする必要のあるリソースの点で一般的にはるかにコストがかかるため、初期のTDDの文献でもモックが優れたプラクティスとして特定されました。
From 例によるテスト駆動開発 （「モックオブジェクト」パターン）：
解決策は、ほとんどの場合、実際のデータベースを使用しないことです。
それでも、必要に応じて、本番コードが実際のデータベースまたは問題の高価なリソースでうまく機能するかどうかを検証する他のいくつかのテストを書くことを妨げるべきではありません。
モックオブジェクトが実際のオブジェクトのように動作しない場合はどうなりますか？モックオブジェクトの一連のテストを用意することで、この戦略を減らすことができます。このテストは、実際のオブジェクトが利用可能になったときに適用することもできます。
全体として、統合と単体テストの全体がTDDに直交していると思います。言い換えると、アトミックビルディングブロックとして小さな赤/緑/リファクタリングフィードバックループを使用しても、アプリケーション開発ワークフロー全体のどのフレーバーを選択するか、または他のどのフィードバックループを囲むかは決定されません-@ lazyberezovskyとして受け入れ駆動される可能性がありますテストファーストのアプローチに忠実である限り、説明、アウトサイドインまたはインサイドアウト、統合中心または分離中心など。
「通常の」tddサイクル、赤-緑-リファクタリングでは、dbアクセスをモックする必要があります。このユニットテストが使用され、テストされる部分はできるだけ小さくする必要があります。しかし、統合テストを行うことは、すべてのプロジェクトにとって必須です。