Похоже, что вы выполняете интеграционный тест , а не модульный тест, так как похоже, что вы используете реальные зависимости тестируемого класса (класс установщика). В модульном тесте вы вводите макет или заглушки для имитации зависимостей.
Интеграционные тесты обычно требуют больше настроек, чем модульные тесты, так как они
- Настройка и подтверждение любых предварительных условий, например, что драйвер не установлен перед запуском теста. Модульные тесты не должны проверять предварительные условия, за исключением редких случаев.
- Запустите тестируемую функцию, например, установка.
- Утверждение любого постусловия, например номер водителя + 1 и т. д.
Редактировать
Я дам вам свое определение единицы измерения, интеграции и сквозного теста, поскольку оно может отличаться от чьего-либо определения. Независимо от моего определения, тестирование того, что вы можете установить свой продукт, является очень действительным тестом. Таким образом, следующее - только моя (потенциально неправильная) точка зрения.
Модульный тест
Модульный тест полностью изолирован и может выполняться без каких-либо внешних зависимостей , таких как базы данных, файловая система, внешние веб-сервисы, триггеры (например, задание cron) и т. Д. Все одноранговые объекты могут быть экстернализованным (либо издеваться, либо ошарашиваться), чтобы тест максимально фокусировался на только , тестирующем тестируемый класс, а не его зависимости.
Интеграционный тест
Проверяет класс, который абстрагирует внешний ресурс. Для меня интеграционные тесты очень похожи на юнит-тесты, но требуют внешнего (и часто медленного) ресурса и могут потерпеть неудачу, потому что ресурс не работает.
Сквозная проверка
Тест, выполняющий функцию с использованием интерфейса приложения, настроенного в производственном режиме. Интерфейс приложения может быть настольным приложением, веб-интерфейсом, веб-сервисами, последовательным портом и т. Д. Ключевым моментом здесь является то, что тест охватывает взаимодействие всех компонентов (протокол). Обычно это самые медленные тесты.
У меня такое ощущение, что вы проводите интеграционный тест, поскольку вы тестируете только класс , который выполняет установку, но это может быть сквозной тест, в зависимости от того, какой интерфейс вы используете.
Пример
Позвольте привести пример из моего текущего проекта. Одна из функций включает извлечение аудио из видеофайла. Для этого я вызываю инструмент командной строки под названием FFmpeg. Чтобы иметь возможность тестировать код, я отделил код, который вызывает командную строку от логики бизнес-процессов в разных классах, таким образом я могу выполнить модульное тестирование бизнес-логики, передав макет AudioExtractor, Теперь тесты Audio Extractor являются «интеграционными тестами», так как я тестирую только этот класс, и для этого класса и внешнего ресурса требуется двоичный файл ffmpeg, который должен быть установлен на компьютере.
Тест Audio Extracto немного сложнее, потому что он должен проверить, что
- Предварительные условия перед запуском теста:
- Тестовый видеофайл присутствует.
- Аудиофайл отсутствует.
- Двоичный файл установлен и является исполняемым.
- Постусловия после теста
- Аудио файл создан
- Звуковой файл действителен
- На тесте снести
- аудиофайл должен быть удален.
Я делаю большинство этих проверок с помощью пользовательских hamcrest matchers (которые в конечном итоге являются вспомогательными классами). Да, и следует иметь в виду, что если одно из предварительных условий не выполнено, это не означает, что код нарушен, но тест не может быть выполнен, что является скорее предупреждением, чем ошибкой.
Я думаю, что кое-что важное - тест должен описывать взаимодействия и оставаться на правильном уровне абстракции, что, вероятно, вы делаете, представляя помощников.