2009-11-08 41 views
5

Được rồi vì vậy gần đây tôi đã cố gắng truy cập vào IoC. Tuy nhiên, tôi tiếp tục chạy vào một rào cản - đó là thực tế là tôi thích sử dụng các đối tượng giả.Thực hành tốt nhất cho các bài kiểm tra đơn vị, đối tượng giả, và ioc

Cài đặt nhanh chóng và không gây đau đớn. Tuy nhiên, nếu tôi sử dụng IoC trên tất cả các vị trí trong mã của mình thì nó buộc tôi tạo các cài đặt thử nghiệm (và cấu hình) của các đối tượng của tôi thay vì sử dụng các đối tượng giả (ví dụ: sử dụng moq).

Kết quả cuối cùng là tôi kết thúc với các tệp cấu hình khổng lồ để thử nghiệm.

Ngoài ra còn có nhiều trường hợp thử nghiệm khi tôi yêu cầu các hành vi khác nhau trong các lớp học của mình trên cơ sở thử nghiệm. Với các đối tượng moq, điều này cực kỳ dễ dàng. Làm thế nào bạn sẽ làm điều gì đó tương tự với IoC?

Mọi trợ giúp sẽ được đánh giá cao.

Cảm ơn,
Mike

+0

Bạn có thể cung cấp thêm thông tin về sự cố không? Tôi không hiểu tại sao bạn lại gặp vấn đề. Có thể một mẫu mã? –

+0

Nếu bạn đang sử dụng tiêm, các phụ thuộc trong lớp của bạn thường được tiêm vào hàm tạo hoặc các thuộc tính - vì vậy trong bài kiểm tra của bạn, bạn nên có tất cả các đường nối cần thiết để thay thế những gì được chèn bởi các mocks. Bạn có thể xây dựng trên một trường hợp cụ thể mà bạn đang đấu tranh với? – Mathias

+0

Tại sao bạn sử dụng một thùng chứa IOC để thử nghiệm đơn vị? – mwjackson

Trả lời

5

IoC nên sử dụng các đối tượng giả dễ dàng hơn, không khó khăn hơn.

Một số khung công tác IoC Container sẽ cho phép bạn xác định các đối tượng có sẵn để tiêm; với Moq bạn chỉ cần thiết lập cho myMockObject.Object.

EDIT: Ví dụ về cấu hình Unity với một giả:

var mockService = new Mock<IMyService>(); 
container.RegisterInstance<IMyService>(mockService.Object); 

Là một thay thế, bạn chỉ có thể vượt qua các đối tượng giả vào constructor của lớp dưới kiểm tra (đối với constructor injection) và bỏ qua các container IoC hoàn toàn trong các bài kiểm tra đơn vị của bạn.

EDIT: Câu trả lời của Josh là một ví dụ hay về giải pháp thay thế. Tôi thường đi với giải pháp của mình thay vì cấu hình lại container.

+0

Đẹp cho biết cách sử dụng IoC để thử nghiệm. Chúng tôi đã phải cuộn IoC của riêng mình để sử dụng với WCSF trong bối cảnh web. Thật dễ dàng để làm và kết thúc là một bài tập tuyệt vời trong việc hiểu các mẫu Dependency Injection và IoC. – Josh

3

Tôi yêu IoC và tôi yêu tôi một số đối tượng Mock ...

Không có xung đột với hai điều này. Nếu bạn đang làm bất kỳ loại Dependency Injection thì bạn chỉ cần tạo các đối tượng giả bằng cách sử dụng khung mocking yêu thích của bạn và sau đó chuyển chúng vào SUT của bạn.

[Test] 
public void AnAwesomeTest() 
{ 
    IDependencyOne d1 = MyMocker.Create<IDependencyOne>(); 
    IDependencyTwo d2 = MyMocker.Create<IDependencyTwo>(); 

    //Constructor injection 
    SUT sut = new SUT(d1); 

    //Property Injection 
    sut.DependantProperty = d2; 

    //Do some stuff and Assert 
} 
+0

+1. Lưu ý rằng nó sẽ là "SUT mới (d1.Object)" với Moq. – TrueWill

+0

Thú vị. Tôi đã quen với RhinoMocks ... nếu cú ​​pháp không cho nó đi. – Josh

+0

@Josh: Một khác biệt là d1 và d2 sẽ thuộc loại Mock . Nhược điểm là phải làm .Object để có được ở giao diện, upside là có thể thiết lập mong đợi trên d1 và d2 trực tiếp. Đó là giá trị so sánh/tương phản các thư viện; họ có những triết lý khác nhau. Tôi chuyển từ Rhino sang Moq một thời gian trước. – TrueWill

Các vấn đề liên quan