この場合、単体テストは最初に書かれているため、求められる解決策の形と挙動を示す設計ドキュメントの役割を果たす。それは細部の実装ではなく、実装はプログラマーに任せられている。「動きそうな最もシンプルな事を行なう」慣例に従えば、テストをパスできる最も簡単な解決法は以下のようなものだろう。インタフェースと実装の分離.あるクラスは他のクラスを参照しているため、あるクラスのテストはしばしば別のクラスのテストに影響してしまう。この一般的な例は、データベースに依存しているクラスである。クラスをテストするために、テスターは、しばしばデータベースと対話するコードを書く。これは間違いである。なぜなら単体テストは自分のクラスの境界を超えるべきではないし、特にそのようなプロセス/ネットワーク境界を超えることは許されない。その理由は単体テストスイートで受け入れがたい性能問題が起こりうるからである。また、そのように単体テストの境界を超えることは統合テストになり、テストが失敗したときに、そのコンポーネントが失敗の原因かどうかが分からなくなってしまう。フェイク、モック、統合テストを参照のこと。その代わりに、ソフトウェア開発者は、データベースクエリの周りに抽象的なインタフェースを作成し、専用のインタフェースを持つモックオブジェクトを実装する必要がある。この必要な付属物をコード(ネットで有効な結合)から抽象化し、独立したユニットは以前よりも徹底的にテストすることができる。この結果、高品質でかつ保守性があるユニットができあがる。パラメータ化された単体テスト.単体テストの制限.