Как автоматизировать интеграционное тестирование?

Question

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

Мой главный вопрос: что вы делаете для тестирования этих классов?

• Я не считаю, что установка базы данных на мой CI-сервер - это хорошая практика, но есть ли у вас другие варианты?

• Должен ли я создать другой сервер с другими инструментами CI со всеми внешними зависимостями?

• Должен ли я запускать интеграционный тест на моем CI так часто, как мои юнит-тесты?

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

Мне бы хотелось узнать, как у вас дела в реальном мире.

Answer 1

Я хотел бы знать, как вы делаете в реальный мир?

В реальном мире не существует простого предписания о том, что делать, но есть одна основополагающая истина: вы хотите отследить ошибки / ошибки / тестовые сбои как можно скорее после их появления. Пусть это будет вашим гидом; все остальное - техника.

Пара общих техник:

• Параллельные тесты. Это мое предпочтение; Мне нравится иметь две системы, каждая из которых работает со своим собственным экземпляром CruiseControl * (для которого я являюсь коммиттером), одна выполняет модульные тесты с быстрой обратной связью (<5 минут), в то время как другая система постоянно выполняет интеграционные тесты. Мне это нравится, потому что это минимизирует задержку между тем, когда происходит проверка, и системный тест может ее поймать. Недостатком, который не нравится некоторым людям, является то, что вы можете получить несколько сбоев теста для одной и той же регистрации, как с ошибкой модульного теста, так и с ошибкой интеграционного теста. Я не считаю это большим недостатком на практике. </p>

• Модель жизненного цикла, в которой системные / интеграционные тесты запускаются только после прохождения модульных тестов. Такие инструменты, как AnthillPro *, построены вокруг этой модели, и этот подход очень популярен. В своей модели они берут артефакты, прошедшие модульные тесты, разворачивают их на отдельном промежуточном сервере, а затем запускают там системные / интеграционные тесты.

Если у вас есть дополнительные вопросы по этой теме, я бы порекомендовал конференцию по непрерывной интеграции и тестированию (CITCON) и / или список рассылки CITCON .

• Существует множество CI и встроенных средств автоматизации процессов . Это просто представители своего класса инструментов.

Answer 2

Чаще всего применяемый мною подход заключается в немедленном запуске модульных тестов при регистрации и более длительных интеграционных тестах с фиксированными интервалами (возможно, на другом сервере; это действительно зависит от ваших предпочтений). Я также видел интеграционные тесты, разбитые на «кратковременные» интеграционные тесты и «длительные» интеграционные тесты, которые выполняются с разными интервалами (например, «краткосрочные» тесты запускаются каждый час, а «длинные»). "бегущие" тесты выполняются в одночасье).

Настоящей целью любого автоматизированного тестирования является получение обратной связи с разработчиками настолько быстро, насколько это возможно. Имея это в виду, вы должны запускать интеграционные тесты настолько часто, насколько это возможно. Если длина ваших интеграционных тестов сильно различается, вам следует чаще запускать более быстрые интеграционные тесты и реже медленные интеграционные тесты. Частота выполнения любого набора тестов зависит от того, сколько времени потребуется на выполнение всех тестов, и насколько разрушительными будут тесты для более коротких тестов (включая юнит-тесты).

Я понимаю, что это не отвечает на весь ваш вопрос, но я надеюсь, что это даст вам некоторые идеи по поводу планирования.

Answer 3

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

Сетевые службы - по определению - также могут быть установлены где-то еще.

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

Answer 4

Я не знаю, на какой ты платформе, но я использую Java. Там, где я работаю, мы создаем интеграционные тесты в JUnit и внедряем соответствующие зависимости, используя DI-контейнер, такой как Spring. Они работают с реальным источником данных, как самими разработчиками (обычно небольшим подмножеством), так и сервером CI.

На мой взгляд, как часто вы запускаете интеграционные тесты, зависит от того, сколько времени они требуют для запуска. Запускайте их как можно чаще. Не допускайте к этому реального человека и разрешите ему или ей запускать ручные системные тесты в областях, для которых сложно или слишком дорого автоматизировать тестирование (например, правописание, расположение различных компонентов графического интерфейса). Оставьте редактирование файлов конфигурации на машине. Там, где я работаю, на компьютерах установлены системные переменные (DEV; TEST и т. Д.), И приложение может выбрать файл конфигурации на основе этого.