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

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

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

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

7 голосов | спросил Wesley Hill 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 15:44:04 +0300000000pmThu, 11 Feb 2010 15:44:04 +030010 2010, 15:44:04

3 ответа


0

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

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

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

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

ответил S.Lott 12 FebruaryEurope/MoscowbFri, 12 Feb 2010 01:40:05 +0300000000amFri, 12 Feb 2010 01:40:05 +030010 2010, 01:40:05
0

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

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

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

  1. создать базу данных, о которой идет речь
  2. запустить свои тесты
  3. снова удалите базу данных после последнего теста

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

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

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

ответил Mark Seemann 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 16:00:58 +0300000000pmThu, 11 Feb 2010 16:00:58 +030010 2010, 16:00:58
0

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

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

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

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

и т.д ...

ответил Max Galkin 11 FebruaryEurope/MoscowbThu, 11 Feb 2010 16:04:31 +0300000000pmThu, 11 Feb 2010 16:04:31 +030010 2010, 16:04:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132