Sử dụng IoC để kiểm tra đơn vị

Làm cách nào để sử dụng IoC Container để kiểm tra đơn vị? Có hữu ích khi quản lý mocks trong một giải pháp khổng lồ (hơn 50 dự án) bằng IoC không? Bất kỳ kinh nghiệm? Bất kỳ thư viện C # nào hoạt động tốt để sử dụng nó trong các bài kiểm tra đơn vị?

Nói chung, một Bộ chứa DI không cần thiết để kiểm thử đơn vị vì kiểm thử đơn vị là tất cả về việc phân tách trách nhiệm.

Hãy xem xét một lớp sử dụng Constructor Injection

public MyClass(IMyDependency dep) { }

Trong toàn bộ ứng dụng của bạn, có thể có một biểu đồ phụ thuộc rất lớn ẩn đằng sau IMyDependency, nhưng trong một bài kiểm tra đơn vị, bạn san bằng tất cả thành một bài kiểm tra kép duy nhất .

Bạn có thể sử dụng các mô phỏng động như Moq hoặc RhinoMocks để tạo Test Double, nhưng không bắt buộc.

var dep = new Mock<IMyDependency>().Object;
var sut = new MyClass(dep);

Trong một số trường hợp, có thể có một vùng chứa tự động mô phỏng , nhưng bạn không cần phải sử dụng cùng Vùng chứa DI mà ứng dụng sản xuất sử dụng.

Làm cách nào để sử dụng Ioc Container để kiểm tra đơn vị?

IoC sẽ thực thi các mô hình lập trình sẽ làm cho việc kiểm thử đơn vị một cách cô lập (tức là sử dụng mô hình) dễ dàng hơn: sử dụng các giao diện, không có new (), không có singleton ...

Nhưng việc sử dụng IoC container để thử nghiệm không thực sự là một yêu cầu, nó sẽ chỉ cung cấp một số phương tiện, ví dụ như tiêm mocks nhưng bạn có thể làm điều đó theo cách thủ công.

Có hữu ích khi quản lý mocks trong một giải pháp khổng lồ (hơn 50 dự án) bằng IoC không?

Tôi không chắc ý của bạn khi quản lý mocks bằng IoC. Dù sao đi nữa, các thùng chứa IoC thường có thể làm được nhiều việc hơn là chỉ tiêm mocks khi cần thử nghiệm. Và nếu bạn có hỗ trợ IDE tốt để có thể tái cấu trúc, tại sao lại không sử dụng nó?

Bất kỳ kinh nghiệm?

Đúng vậy, đối với một giải pháp khổng lồ, bạn cần hơn bao giờ hết một giải pháp không dễ xảy ra lỗi và tái cấu trúc không gây hại (tức là thông qua một vùng chứa IoC an toàn loại hoặc hỗ trợ IDE tốt).

Tôi thường sử dụng một vùng chứa IoC trong các thử nghiệm của mình. Đúng ra, chúng không phải là "bài kiểm tra đơn vị" theo nghĩa thuần túy. IMO Chúng có nhiều BDDish hơn và tạo điều kiện tái cấu trúc. Kiểm tra ở đó để cung cấp cho bạn sự tự tin để tái cấu trúc. Các bài kiểm tra viết kém có thể giống như đổ xi măng vào mã của bạn.

Hãy xem xét những điều sau:

[TestFixture]
public class ImageGalleryFixture : ContainerWiredFixture
{
    [Test]
    public void Should_save_image()
    {
        container.ConfigureMockFor<IFileRepository>()
            .Setup(r => r.Create(It.IsAny<IFile>()))
            .Verifiable();

        AddToGallery(new RequestWithRealFile());

        container.VerifyMockFor<IFileRepository>();
    }

    private void AddToGallery(AddBusinessImage request)
    {
        container.Resolve<BusinessPublisher>().Consume(request);
    }
}

Có một số điều xảy ra khi thêm hình ảnh vào thư viện. Hình ảnh được thay đổi kích thước, hình thu nhỏ được tạo và các tệp được lưu trữ trên AmazonS3. Bằng cách sử dụng vùng chứa, tôi có thể dễ dàng cô lập hành vi mà tôi muốn kiểm tra hơn, trong trường hợp này là phần tồn tại.

Tiện ích mở rộng vùng chứa tự động mô phỏng rất hữu ích khi sử dụng kỹ thuật này: http://www.agileatwork.com/auto-mocking-unity-container-extension/

Sử dụng các vùng chứa có khả năng giải quyết các dịch vụ chưa đăng ký / không xác định như SimpleInjector , DryIoc (mỏ của nó) có thể trả về các đoạn giễu cho các giao diện chưa được triển khai.

Điều đó có nghĩa là bạn có thể bắt đầu phát triển với triển khai đơn giản đầu tiên và các phụ thuộc được chế tạo của nó, và thay thế chúng bằng thứ thực khi bạn tiến bộ.