Переопределение регистрации IOC для использования с интеграционным тестированием - PullRequest
Новая
       41

Переопределение регистрации IOC для использования с интеграционным тестированием

1 голос
/ 04 августа 2011

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

Предположим, у меня есть пара классов: 

public class EmailComposer : IComposer
{
    public EmailComposer(IEmailFormatter formatter)
    {
        ...
    }
    ...
    public string Write(string message)
    {
        ...
        return _formatter.Format(message);
    }
}

ОК, так что для использования в реальном приложении (здесь я использую автофак) я бы создал модуль и сделал что-то вроде: 

    protected override void Load(ContainerBuilder containerBuilder)
    {
        containerBuilder.RegisterType<HtmlEmailFormatter>().As<IEmailFormatter>();
    }

Прекрасно понимает и прекрасно работает.

Когда дело доходит до модульных тестов, я бы вообще не использовал контейнер IOC, а просто выполнял макет форматера, когда выполняю свои тесты. Снова прекрасно работает.

Хорошо, теперь, когда дело доходит до моих интеграционных тестов ... В идеале я бы запустил полный стек во время интеграционных тестов, но давайте представим, что HtmlEmailFormatter - это медленный внешний WebService, поэтому я решил, что в моих интересах использовать вместо этого Test Double. Но ... я не хочу использовать Test Double во всех моих интеграционных тестах, только подмножество (набор быстрых тестов в стиле дымовых тестов).

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

Итак, настоящий вопрос:

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

1 Ответ

1 голос
/ 04 августа 2011

Я бы сказал, что для этого вы используете SetUp и TearDown (NUnit) или ClassInitialize и ClassCleanup (MSTest).При инициализации вы регистрируете свой временный тестовый класс, а при очистке вы восстанавливаете его в нормальное состояние.

Наличие в контейнере DI указания всех зависимостей дает вам преимущество, заключающееся в разрешении целого графа объектов зависимостей.Однако если есть один тест, в котором вы хотите использовать другую реализацию, я бы вместо этого использовал среду Mocking.

...