TDDと3層アーキテクチャ

Question

3層アーキテクチャでTDDを実装する必要があります。

ストリングのチャーターの出現をテストしたり、StackのPop機能をテストしたりするときには、書籍やブログの例が意味を持ちます.NTierアプリケーションの場合、UI、ビジネス層、データ層があります順番にデータ層が必要なストアドプロシージャを呼び出し、データを取得します。

TDDの背後にある概念は、テストを単独で実行することです。つまり、データを偽装するか、偽装する必要があります。

しかし、この方法論に関する私の疑問は、TDDテストが何をすべきかということです。 私が理解していることは、たとえば、GetCustomer関数が期待される結果を返すかどうかをテストすることです。

今私の質問は、ストアドプロシージャがバグを持っている場合、TDDはデータがバグのストアドプロシージャを使って抽出されないのでバグを捕まえません。 ビジネスをテストする方法&ストアドプロシージャを呼び出すデータ層機能とストアドプロシージャには、すべてのビジネスルールが実装されています。

CRUD操作のためのTDDの実装方法は？

任意の例は、完全にTDD

Answer 1

テストは、機能やビジネス要件が満たされていることを証明するために書かれている

よろしくの概念を理解することは非常に参考になります。したがって、使用しているクラスのパブリックインターフェイスに対してコードを作成します。パブリックインターフェイスは、内部およびプライベートクラスにドリルダウンします。より低いレベルで例外がスローされた場合、または関数が間違ったデータを返す場合は、ビジネスルールに対してテストでそれを取得します。

たとえば、Employeeがビジネスクラスで、EmployeeSerializer.GetAll（）を呼び出す場合は、Employee.GetAllをテストする必要があります。 EmployeeSerializer（）が正しいデータを返さない場合、私はそれを知ります。 EmployeeSerializerが予期しない例外をスローすると、私はそれを知ります。 EmployeeSerializerが正しい例外をスローしない場合、私はそれを知ります。

実装の詳細を検証するためにテストをコード化しないでください。ビジネスルールをテストするためにそれらをコード化してください。つまり、ビジネスオブジェクトをテストします。この努力を容易にするために、私はデータアクセスが内部を対象としているので、それらを使用する予定のビジネスコンテキスト外でテストすることはできません。

しかし、それは私です。他の人たちとは異なる意見があると確信しています。

追加：ビジネスルールを可能な限りストアドプロシージャから守ってください。また、[Setup]と[TearDown]を使用して、既知のテストを設定します。テストはビジネスルール全体をテストすることを忘れないでください。テストが孤立して実行され、テストが完了したときに環境を元の状態に戻すことができる限り、できるだけ多くの作業を自由に行うことができます。したがって、データを挿入する場合は、そのことを行うビジネスクラスメソッドがあることを確認してください。更新、削除、および選択についても同じです。

Answer 2

まず、私はモック（あなたがモックの役割を...データ/オブジェクトではない）についてもう少し詳しくお読みになりたいと思います。

W.r.t.あなたの例には、私は持っていた

1. プレゼンテーションクラス/ビューモデル（あなたのUI層）に対するユニットテスト。ここで私はビジネスレイヤー/ロールを模倣します。プレゼンテーションクラスがサービスの正しいメソッドを呼び出すことを確認してください。X
2. ドメインクラス（ビジネス層）に対するユニットテスト。ここで私はデータアクセス層を模擬します。
3. MyRepository.GetCustomer（）が実際に実際のテストDBからデータを正しくフェッチすることをテストする統合テスト。理想的にはStoredProcのバグを捕まえてここにフラグを立てるべきです。

これに加えて、契約の両側にある2人の当事者が、他の人がどのように行動すべきかについて異なる考えがあるかもしれません。そのためには、すべてのコンポーネントを一緒に配線して実行するエンドツーエンドの受け入れテストを作成します（実稼働中のように）。

上記のすべてにTDDを使用できます。