Использование МОК для модульного тестирования

Question

Использование МОК для модульного тестирования

Как можно использовать контейнер IoC для модульного тестирования? Полезно ли управлять mocks в огромном решении (50+ проектов) с помощью IoC? Какие-нибудь впечатления? Любые библиотеки C#, которые хорошо работают для использования его в модульных тестах?

788 4

inversion-of-control unit-testing c#mocking

4 ответов:

Comments

Ничего не найдено.

Mark Seemann · Accepted Answer · 2014-02-14 09:32:22

вообще говоря, контейнер не должен быть необходим для модульного тестирования, потому что модульное тестирование-это все о разделении обязанностей.

рассмотрим класс, который использует инъекцию конструктора
public MyClass(IMyDependency dep) { }
во всем вашем приложении может быть, что есть огромный график зависимости, скрытый за IMyDependency, но в модульном тесте вы сглаживаете все это до одного Двойной Тест.

вы можете использовать динамические глумится, как для Moq или быть в RhinoMocks сгенерируйте тестовый двойник, но это не обязательно.
var dep = new Mock<IMyDependency>().Object;
var sut = new MyClass(dep);
В некоторых случаях авто-насмешливо контейнер может быть приятно иметь, но вам не нужно использовать тот же контейнер DI, который использует производственное приложение.

Pascal Thivent · Accepted Answer · 2009-09-23 16:32:58

как можно использовать контейнер Ioc для модульного тестирования?

IoC будет применять парадигмы программирования, которые сделают модульное тестирование в изоляции (т. е. с использованием насмешек) проще: использование интерфейсов, отсутствие новых (), отсутствие синглетов...

но использование контейнера IoC для тестирования на самом деле не является требованием, он просто предоставит некоторые средства, например, инъекцию насмешек, но вы можете сделать это вручную.

полезно ли управлять издевается в огромном решение (50 + проектов) с использованием МОК?

Я не уверен, что вы подразумеваете под управлением издевается с помощью МОК. Во всяком случае, контейнеры IoC обычно могут делать больше, чем просто вводить насмешки, когда дело доходит до тестирования. И если у вас есть достойная поддержка IDE, которая делает возможным рефакторинг, почему бы не использовать ее?

любой опыт?

да, на огромном решении вам нужно больше, чем когда-либо, не подверженное ошибкам и рефакторингу-неблагоприятное решение (т. е. либо через тип безопасный контейнер IoC или хорошая поддержка IDE).

Mike Valenty · Accepted Answer · 2013-03-10 17:14:45

Я часто использую контейнер IoC в своих тестах. Конечно, они не являются "модульными тестами" в чистом смысле. ИМО они более Бддиш и облегчают рефакторинг. Тесты существуют, чтобы дать вам уверенность в рефакторе. Плохо написанные тесты могут быть похожи на заливку цемента в ваш код.

рассмотрим следующее:
[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);
    }
}
есть несколько вещей, которые происходят при добавлении изображения в галерею. Изображение изменяется, создается миниатюра, и файлы сохраняются на AmazonS3. С помощью контейнера я могу более легко изолировать только поведение, которое я хочу проверить, что в данном случае является сохраняющейся частью.

автоматическое расширение контейнера насмешки пригодится при использовании этой техники: http://www.agileatwork.com/auto-mocking-unity-container-extension/

dadhi · Accepted Answer · 2014-04-11 16:53:09

использование контейнеров с возможностью разрешения незарегистрированных / uknown услуг, таких как SimpleInjector,DryIoc (его шахта) может возвращать насмешки для еще не реализованных интерфейсов.

Это означает, что вы можете начать разработку с первой простой реализации и ее издевательских зависимостей и заменить их реальной вещью по мере продвижения.