Как вы тестируете инъекцию зависимостей?

Инъекционная инъекция помогает вам unit test ваш код очень хорошо. Но как мы тестируем, будут ли введены правильные зависимости в конечном итоге во время выполнения? Например, у меня есть класс сервиса, который принимает список валидаторов сервисов. Поскольку список валидаторов вводится контейнером DI, как мы можем убедиться, что правильные валидаторы введены? Что делать, если какой-либо разработчик ошибочно удаляет валидатор из списка. Даже если мы пишем тесты на инъекцию зависимости, мы не можем утверждать на всех зависимостях без нарушения инкапсуляции. Единственный способ - это интеграционный тест, который подтверждает поведение валидации службы. Если поведение службы является сложным, тогда становится сложно записывать интеграционные тесты. Есть идеи??

Ответ 1

Перефразируя ваш вопрос:

Я проверил отдельные компоненты моего приложения, и все они работают, но как я знаю, что приложение в целом работает?

Хорошие новости

Подумайте, насколько хорошо вы находитесь в позиции, по сравнению с тем, чтобы спросить:

Я написал весь этот код сейчас, как я узнаю, работает ли приложение?

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

Тест Большой

Теперь, чтобы перейти к ответу на ваш вопрос, вы можете написать автоматический тест, чтобы подтвердить, что конкретный валидатор возвращается вашим контейнером внедрения зависимостей. Еще лучше, я одобряю написание тестов, которые: -

  • Попросите контейнер DI для объекта (за которым лежит график взаимодействующих объектов, например, список валидаторов)
  • Попросите объект выполнить его функцию (подтвердите эти данные)
  • Утвердить результат (например, ошибка проверки)

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

Если класс не доставляет особых хлопот, я предпочитаю тестировать на этом уровне, потому что он позволяет больше тестов выдерживать рефакторинг. Классы с цикломатической сложностью 1 не требуют отдельного тестирования, если оно проводится в рамках более крупного теста. Занятия с более высокой цикломатической сложностью возможны.

Много тестов, но работает ли это?

Даже тогда вы можете быть удивлены: а работает ли все это?

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

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