私たちは、開発が開始されてからずっと後にテスト駆動設計の採用を開始したプロジェクトを実行しています。
単体テストと統合テストの両方があります。統合テストは実際のデータベースで実行され、テストが実行される前に既知の状態で初期化されます。
テストを書いていると、「標準的な方法」でテストできたクラスよりも、分離してモックオブジェクトを使用して、実際にはより高速でクリーンになっていることに気付き始めます (コードを短く読みやすく理解しやすい)。複雑なモック オブジェクトのセットアップでテスト クラスを乱雑にするのではなく、データベースと直接対話する実際のオブジェクト/サービスを使用します。
このアプローチに問題はありますか？
実際のオブジェクト/サービスを使用している場合、テストが失敗した理由はわかりません。たとえば、サービスの実装で何かを変更したり、データベース フィールドの名前を変更したり、ネットワークがダウンしたりして、50 件の「ユニット」テストに失敗しました。また、この場合、テスト駆動開発を行うことはできません。テストを作成する前に、テスト対象のクラスに必要な依存関係を実装する必要があるためです。サービスの利用者が必要とする API を予測できますか? これにより、まったく使用されていない API とコード (パラメーター、メソッドなど) が使用しにくくなります。
テストでモックを配置するのに多くの労力がかかる場合、次のようになります。