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

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

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

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

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

Ответ 1

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

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

Пара общих методов:

Тестирование выполняется параллельно. Это мое предпочтение; Мне нравится иметь две системы, каждая из которых запускает собственный экземпляр CruiseControl * (для которого я являюсь коммиттером), один из которых запускает модульные тесты с быстрой обратной связью (< 5 минут), в то время как другая система постоянно проводит интеграционные тесты. Мне это нравится, потому что это минимизирует задержку между тем, когда происходит проверка, и системный тест может ее поймать. Недостатком того, что некоторые люди не любят, является то, что вы можете завершить несколько отказов тестов для одной и той же проверки, как с ошибкой unit test, так и с ошибкой интеграции. Я не считаю это серьезным недостатком на практике.
Модель жизненного цикла, в которой тесты системы/интеграции выполняются только после прохождения модульных тестов. Существуют такие инструменты, как AnthillPro *, которые построены вокруг этой модели, и этот подход очень популярен. В своей модели они берут артефакты, прошедшие модульные тесты, разворачивают их на отдельный промежуточный сервер и затем запускают там тесты системы/интеграции.

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

Существует множество

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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