TDD の道を進み、コードのテスト容易性を本当に確保したい場合は、staticクラスを削除する必要があります。もう 1 つのポイントは、TDD を使用する場合は、テストの作成を開始して設計を作成する必要があるということです。ただし、ここでは、設計をどのようにしたいかについての確固たる考えがすでにあります...
あなたが指摘したように、DAL はこの方法で 3 回テストされますが、それは最悪の部分ではありません。最悪の部分は、ApiController または BLL を単独でテストできないことです。つまり、テストで何か問題が発生した場合、どのクラスが失敗しているかがわからず、単体テストの目的が無効になります。失敗の原因を素早く特定します。
私がすることは次のようなものです：
ICarDAL (interface) -> SelectCar, SelectCars, InsertCar, UpdateCar, DeleteCar
CarDAL は上記のインターフェースを実装します。
ICarBLL (interface) -> GetCar, GetCars, PostCar, PutCar, DeleteCar
BLL が Api メソッドを反映しているという事実を大まかに説明しましょう。私の考えでは、BLL は使用レイヤーとは独立してロジックを提供する必要があるため、GetCars、AddCar、EditCar、CreateCar などのメソッドを使用する必要があります。名前が異なるだけかもしれませんが、それも重要です。この BLL がデスクトップに使用される瞬間たとえば、PostCar と PutCar は無意味になります。
CarBLL は上記を実装します。CalBLL は DAL を使用するため、そのコンストラクターは次のようになります。
public CarBLL(ICarDAL dal)
{
this.dal = dal;
}
コントローラーの場合:
CarApiController -> GetCar, GetCars, PostCar, PutCar, DeleteCar
CarApiController にも同様のコンストラクターがあります。
public CarApiController(ICarBLL bll)
{
this.bll = bll;
}
コール スタックは同じままですが、コードは分離されています。ApiController でパラメーター化されたコンストラクターを使用するには、アプリケーションにある種の IoC コンテナーを登録する必要があることに注意してください。私はこれまでUnityを使用してきましたが、非常に満足しています。
今、私たちは踊ることができます。テストは次のようになります。
コントローラーのテスト:
public void test_that_this_works()
{
ICarBLL mock = new FakeCarBLL();
var controller = new CarApiController(mock);
Assert.That(controller.GetCars.Count(), Is.EqualTo(1));
}
上記を使用すると、常に同じ結果を返す BLL インターフェイスの偽の実装を作成するだけで、コントローラーでの操作が正常に実行されていることを確認できます。BLL テストは似ていますが、DAL の偽の実装を使用して、DB からの一連の結果をシミュレートし、Save メソッドと Select メソッドが正しい回数呼び出されることを確認します (その場合は、RhinoMocksなどのモッキング ライブラリ)
非常に長い回答で申し訳ありませんが、それは非常に複雑で広範な主題です...頑張ってコーディングしてください! :)