0
まず、TDDのかなり新しい開業医であるにもかかわらず、私はそのメリットをかなり売却していると述べます。私はモックを使うことを検討するのに十分なほどの進歩を遂げたように感じ、OOPでモックがどこに合っているかを理解するために真のレンガの壁に当たった。もう1つの疑問の質問
私は見つけられたほど多くの関連する記事/記事を読んできましたが（Fowler、Miller）、模擬方法や時期についてはまだ完全にはっきりしていません。
具体例を挙げておきます。私のアプリケーションには、特定のユースケースに大まかにマップされたサービスレイヤークラス（アプリケーションレイヤーと呼ばれるものもあります）があります。これらのクラスは、パーシスタンス層、ドメイン層、さらには他のサービスクラスと連携することができます。私は良い小さなDIの男の子してきた、彼らはこのようになりますテストの目的など
サンプルサービスクラスのために下塗りしできるように適切に私の依存関係を因数分解している：
public class AddDocumentEventService : IAddDocumentEventService
{
public IDocumentDao DocumentDao
{
get { return _documentDao; }
set { _documentDao = value; }
}
public IPatientSnapshotService PatientSnapshotService
{
get { return _patientSnapshotService; }
set { _patientSnapshotService = value; }
}
public TransactionResponse AddEvent(EventSection eventSection)
{
TransactionResponse response = new TransactionResponse();
response.Successful = false;
if (eventSection.IsValid(response.ValidationErrors))
{
DocumentDao.SaveNewEvent(eventSection, docDataID);
int patientAccountId = DocumentDao.GetPatientAccountIdForDocument(docDataID);
int patientSnapshotId =PatientSnapshotService.SaveEventSnapshot(patientAccountId, eventSection.EventId);
if (patientSnapshotId == 0)
{
throw new Exception("Unable to save Patient Snapshot!");
}
response.Successful = true;
}
return response;
}
}
私はNMockを使って、このメソッドを依存関係（DocumentDao、PatientSnapshotService）とは別にテストしています。次のようにここでテストをからかっに
[Test]
public void AddEvent()
{
Mockery mocks = new Mockery();
IAddDocumentEventService service = new AddDocumentEventService();
IDocumentDao mockDocumentDao = mocks.NewMock<IDocumentDao>();
IPatientSnapshotService mockPatientSnapshot = mocks.NewMock<IPatientSnapshotService>();
EventSection eventSection = new EventSection();
//set up our mock expectations
Expect.Once.On(mockDocumentDao).Method("GetPatientAccountIdForDocument").WithAnyArguments();
Expect.Once.On(mockPatientSnapshot).Method("SaveEventSnapshot").WithAnyArguments();
Expect.Once.On(mockDocumentDao).Method("SaveNewEvent").WithAnyArguments();
//pass in our mocks as dependencies to the class under test
((AddDocumentEventService)service).DocumentDao = mockDocumentDao;
((AddDocumentEventService)service).PatientSnapshotService = mockPatientSnapshot;
//call the method under test
service.AddEvent(eventSection);
//verify that all expectations have been met
mocks.VerifyAllExpectationsHaveBeenMet();
}
この小さな進出に私の考えどのように見えるのは、次のとおりです。
- このテストでは、カプセル化されていない以上、そのうちの多くの基本的なオブジェクト指向の戒律を破るために表示されます。私のテストテスト対象のクラス（つまりメソッド呼び出し）の具体的な実装の詳細を完全に認識しています。クラス内部が変わるたびにテストを更新するのに費やされる時間は、非生産的です。
- 私のサービスクラスは現時点ではかなり単純化されているかもしれませんが、これらのテストでどのような価値が追加されたのかは分かりません。特定のユースケースが指示するように共同オブジェクトが呼び出されていることを保証していますか？このような小さな利益のために、コードの重複は不当に高いようです。
私は何が欠けていますか？
「何が欠けていますか？」 - 冗長コードを除去するためにリファクタリングをテストしますか？つまり、一般的な手順をテスト設定に移動します。 – tvanfosson