Введение зависимостей в тесты
Обычно при использовании внедрения зависимости, единица (и другой) тесты ответственны за создание/насмешку зависимостей системы под тестом и введения их.
Однако иногда сам тест имеет зависимости или должен ввести зависимости в SUT, который он не может самостоятельно создать. Например, при тестировании классов, которые взаимодействуют с базой данных, тест должен знать строки подключения и названия каталога и т.д., которые не могут быть трудно кодированы, так как они - не обязательно то же для всех запускающих тест.
Так, как Вы рекомендовали бы, чтобы тест узнал эти настройки? Некоторые xUnit-разрабатывают среды тестирования, позволяют давать зависимости тестовому приспособлению? Тестовый класс должен иметь статические свойства, которые Вы заполняете прежде, чем запустить все тесты? Тест должен проигнорировать методы DI и просто пойти и получить зависимости от некоторого глобального места?Другие рекомендации?
3 ответа
Когда вы используете среду модульного тестирования для выполнения интеграционных тестов, у вас действительно нет проблем с DI или модульным тестированием.
У вас есть интеграционные тесты, в которых используется мощная среда модульного тестирования.
Поскольку это интеграционные тесты, они отличаются от модульных тестов.«Самостоятельность» больше не в счет.
Лучший способ получить настройки интеграционного теста, которые различаются от пользователя к пользователю, - это получить их так же, как и окончательное приложение. Если вы работаете на Java, у вас может быть файл свойств. В Python у нас есть специальные файлы настроек Django для интеграционного тестирования.
Существует принцип полностью автоматизированных тестов : у вас должна быть возможность получить весь исходный код из репозитория системы управления версиями и просто запустить тесты.
Учитывая, что среда (машина) имеет правильную базу для установки (то есть компилятор, среду тестирования, ядро базы данных, если это необходимо, и т. Д.), Тесты отвечают за настройку своего Fixture перед выполнением тестовых примеров.
Это означает, что для баз данных тесты должны
- создать соответствующую базу данных
- запустить ее тесты
- снова удалить базу данных после последнего тестового примера
Если по какой-то причине вы не можете сделайте это, единственное, что вы действительно можете сделать, - это иметь файл конфигурации в вашей системе управления версиями, который содержит машинно-зависимые записи для всех машин в вашей среде тестирования; например для машины Tst1 строка подключения - это одно значение, а для Tst2 - другое.
Это может очень быстро стать некрасивым, поэтому гораздо проще поручить тестам отвечать за установку и разборку приспособлений, потому что это означает, что они могут просто использовать жестко запрограммированные значения или значения, сгенерированные на месте.
Это действительно не имеет ничего общего с DI ...
DI борется со сложностью зависимостей, в то время как ваши юнит-тесты должны быть в большинстве случаев ОЧЕНЬ простыми. Типичный юнит-тест исследует один изолированный аспект одного изолированного класса. Вместо всех его зависимостей вы создаете макеты и (обычно) внедряете их через конструктор CUT (Class Under Test). Здесь вам обычно не нужны DI-фреймворки.
Но некоторые тесты более высокого уровня все же могут потребовать немокированных зависимостей. Например, вы хотите сделать тесты на большом наборе данных и не хотите создавать специальный поддельный источник данных, поэтому храните их в реальной БД (возможно, вы также делаете некоторые тесты пользовательского интерфейса с этими данными). В этом случае я бы постарался все упростить, инициализируя тесты в методах настройки класса / настройки тестов.
Видите ли, здесь нужно быть осторожным. Всякий раз, когда вы делаете большой, сложный тест, вы:
- Создаете дополнительный сложный код, который потребует усилий по поддержке.
- Создаете тест, у которого нет четкой причины для отказа. Он может не сработать из-за плохого соединения в этот день. Вы не можете полагаться на его результат.
- Создайте тест, который не может быть выполнен легко и быстро, например, при регистрации. Меньше людей будут его выполнять, больше ошибок будет пропущено.
и т.д.