Внедрение зависимостей в тесты

Question

Обычно при использовании внедрения зависимостей модульные (и другие) тесты отвечают за создание / проверку зависимостей тестируемой системы и их внедрение.

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

Итак, как бы вы порекомендовали тесту выяснить эти настройки?Предоставляют ли некоторые тестовые среды в стиле xUnit способ давать зависимости для тестового устройства?Должен ли тестовый класс иметь статические свойства, которые вы заполняете перед запуском всех тестов?Должен ли тест игнорировать практики DI и просто пойти и получить зависимости из какого-то глобального места?Другие предложения?

Answer 1

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

Учитывая, что среда (машина) имеет правильную базу установки (то есть компилятор, инфраструктуру тестирования, ядро ​​базы данных, если это необходимо, и т. Д.), Тесты отвечают за настройку своего Fixture перед выполнением тестовых случаев.

Это означает, что для баз данных тесты должны

1. создать соответствующую базу данных
2. запустить свои тесты
3. снова удалить базу данных после последнего теста

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

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

Это действительно не имеет никакого отношения к DI ...

Answer 2

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

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

Так как они являются интеграционными тестами, они отличаются по типу от юнит-тестов. «Автономность» больше не считается.

Лучший способ получить параметры интеграционного теста, которые варьируются от пользователя к пользователю, - получить их так же, как их получит конечное приложение. Если вы работаете в Java, у вас может быть файл свойств. В Python у нас есть специальные файлы настроек Django для тестирования интеграции.

Answer 3

DI борется со сложностью зависимостей, в то время как ваши юнит-тесты в большинстве случаев должны быть ОЧЕНЬ простыми. Типичный юнит-тест будет рассматривать один изолированный аспект одного изолированного класса. Вместо всех его зависимостей вы создаете макеты и (обычно) внедряете их через конструктор CUT (Class Under Test). Обычно вам здесь не нужны DI-фреймворки.

Но. Очевидно, что некоторые высокоуровневые тесты могут требовать немоделируемых зависимостей. Например, вы хотите проводить тесты для большого набора данных и не хотите создавать специальный поддельный источник данных, поэтому храните его в реальной БД (возможно, вы также проводите некоторые тесты пользовательского интерфейса с этими данными). В этом случае я все равно постараюсь сделать все как можно проще, инициализируя тесты в методах настройки класса / test test.

Видите ли, вам нужно быть осторожным здесь. Всякий раз, когда вы делаете большой, сложный тест, вы:

1. Создайте дополнительный сложный код, который потребует поддержки.
2. Создайте тест, у которого нет явной причины провала. Это может привести к сбою из-за плохой связи в тот день. Вы не можете полагаться на его результат.
3. Создать тест, который не может быть выполнен легко и быстро, например, при регистрации. Чем меньше людей его запустят, тем больше будет ошибок.

и т.д ...