Mã kiểm tra phụ thuộc vào Thư viện doanh nghiệp mặc dù nó không cung cấp giao diện?

Question

Có lẽ tôi cho thấy sự thiếu hiểu biết về tiêm phụ thuộc và thử nghiệm của mình, nhưng tôi không hiểu cách sử dụng tiêm phụ thuộc với các lớp không triển khai giao diện sẽ giúp tôi gì cả khi thử nghiệm?

Ví dụ: trong tài liệu Thư viện doanh nghiệp 5.0, nó thảo luận về việc sử dụng vùng chứa Unity để tạo các phiên bản. Nó nói rằng điều này viện trợ "testability: Nó là tầm thường để cô lập các lớp học từ phụ thuộc khi sử dụng phong cách tiêm phụ thuộc." MSDN

Làm cách nào để sử dụng điều này trong các thiết bị thử nghiệm đơn vị của tôi? Ví dụ của họ có một hàm tạo với tham số là các lớp thay vì giao diện:

public class TaxCalculator 
{ 
    private ExceptionManager _exceptionManager; 
    private LogWriter _logWriter; 

    public TaxCalculator(ExceptionManager em, LogWriter lw) 
    { 
    this._exceptionManager = em; 
    this._logWriter = lw; 
    } 
} 

Answer 1

Để trả lời câu hỏi "Tôi làm cách nào để kiểm tra mã Thư viện doanh nghiệp": bạn không. Thử nghiệm công cụ của người khác là công việc của người khác. Bất kỳ giao diện hoặc trừu tượng nào trong Thư viện doanh nghiệp hoặc bất kỳ thư viện bên thứ ba nào khác tồn tại cho mục đích trừu tượng của riêng chúng, không phải cho mục đích của bạn. Những gì bạn cần làm là xác định giao diện của bạn mô tả nhu cầu của ứng dụng của bạn (ghi nhật ký, lưu bộ nhớ đệm, mã hóa, v.v.) và sau đó viết bộ điều hợp thực hiện giao diện của bạn bằng Thư viện Doanh nghiệp (hoặc thư viện bên thứ ba khác) . Thực hành này được gọi là Dependency Inversion Principle.

Để kiểm tra mã của riêng bạn được thiết kế theo cách này, đối với các bài kiểm tra cấp độ đơn vị/thành phần, bạn sẽ chỉ sử dụng Kiểm tra đôi cho các giao diện bạn đã tự xác định (ví dụ: IMyOwnLogger). Để kiểm tra các bộ điều hợp mà bạn viết để thích ứng với các thư viện của bên thứ ba, bạn sẽ viết các bài kiểm tra tích hợp. Để kiểm tra xem tất cả hoạt động cùng nhau, bạn sẽ viết các bài kiểm tra chấp nhận để thúc đẩy ứng dụng thông qua giao diện người dùng hoặc dưới da.

Để biết thêm thông tin về chế độ xem này, hãy xem bài viết của tôi: "TDD Best Practices: Don't Mock Others".

Answer 2

Tốt hơn là nên lập trình chống trừu tượng thay vì triển khai. Nhưng trừu tượng không phải lúc nào cũng là giao diện. Nó có thể là lớp trừu tượng.

public abstract class LogWriter 
{ 
    public abstract void Write(string message); 
} 

Vì vậy, không có vấn đề để tạo ra mô hình của lớp trừu tượng:

Mock<LogWriter> logWriter = new Mock<LogWriter>(); 
TaxCalculator calc = new TaxCalculator(logWriter.Object); 

Nếu bạn không làm đơn vị thử nghiệm, tôi không thấy bất kỳ vấn đề để vượt qua các thông số không trừu tượng, bởi vì của nguyên tắc YAGNI. Nếu tôi không cần thực hiện ExceptionManager khác, thì tại sao tôi nên tạo trừu tượng hóa nó? Nhưng nếu tôi làm TDD, thì chắc chắn tôi sẽ cần ít nhất hai lần triển khai lớp học. Một thực tế và một mô hình/sơ khai.

Btw phải cẩn thận với service locator anti-pattern.

CẬP NHẬT: Không nhận được rằng bạn đang đề cập đến các lớp học hiện tại của Microsoft.Practices.EnterpriseLibrary (mà tôi không thích). Tôi nghĩ đó là một thất bại thiết kế khác của nhóm Microsoft.Practices. Tạo lớp ExceptionManager 'kín' không thực hiện bất kỳ lớp giao diện/lớp cơ sở nào làm chết tính kiểm thử.

Answer 3

Miễn là lớp học của bạn không phải là sealed, khuôn khổ mocking có thể có thể tạo một lớp con hoạt động chính xác như triển khai giao diện giả lập. Có nhiều cân nhắc khi bạn phụ thuộc vào các lớp cụ thể - sealed các phương thức sẽ vẫn thực thi trên lớp được chỉ định, v.v. - nhưng nói chung là không khác gì tùy thuộc vào giao diện.