Уиттакер . - Как тестируют в Google

Средними тестами нужно управлять через тестовую инфраструктуру. Из-за большего времени прогона они запускаются реже. В основном эти тесты создаются и выполняются силами разработчиков в тестировании.

На заметку

Малые тесты проверяют поведение отдельной единицы кода. Средние тесты проверяют взаимодействие одного или нескольких модулей кода. Большие тесты проверяют работоспособность системы в целом.

Имитация внешних сервисов для средних тестов приветствуется, но не обязательна. Это может быть полезно, если нужно увеличить быстродействие. Там, где полноценная имитация сервисов неоправданна, для повышения производительности можно использовать облегченные вариации, например встроенные в память базы данных.

Большие и громадные тесты за пределами Google называют системными тестами, или сквозными тестами. Большие тесты оперируют на высоком уровне и проверяют, что система работает как единое целое. Эти тесты задействуют все подсистемы, начиная с пользовательского интерфейса и заканчивая хранилищами данных, как это показано на рис. 2.4. Они могут обращаться к внешним ресурсам, таким как базы данных, файловые системы и сетевые службы.

Как мы используем размеры тестов в общей инфраструктуре

Автоматизацию тестирования трудно сделать универсальной. Чтобы все проекты в большой IT-компании могли работать с общей тестовой инфраструктурой, она должна поддерживать множество разных сценариев запуска тестов.

Например, вот некоторые типичные сценарии запуска тестов, которые поддерживает общая инфраструктура тестирования Google.

— Разработчик хочет скомпилировать и запустить малый тест и тут же получить результаты.

— Разработчик хочет запустить все малые тесты для проекта и тут же получить результаты.

— Разработчик хочет скомпилировать и запустить только те тесты, которые связаны с последним изменением кода, и тут же получить результаты.

— Разработчик или тестировщик хочет собрать данные о покрытии кода в конкретном проекте и посмотреть результаты.

— Команда хочет прогонять все малые тесты для своего проекта каждый раз при создании списка изменений и рассылать результаты всем участникам команды.

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

— Команда хочет еженедельно собирать статистику о покрытии кода и отслеживать его прогресс со временем.

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

Система выполнения тестов Google отличает быстрые задания от медленных по информации о размере тестов. У каждого размера есть верхняя граница времени выполнения теста (табл. 2.1). Размер определяет и потенциальную потребность в ресурсах (табл. 2.2). Система прерывает выполнение и сообщает об ошибке, если тест превышает выделенное для его категории время или доступный объем ресурса. Это мотивирует разработчиков в тестировании назначать правильные метки размеров тестов. Точное определение размеров тестов позволяет системе строить эффективное расписание.

Малые тесты

Средние тесты

Большие тесты

Огромные тесты

Временные цели

(на метод)

Исполнение меньше чем за 100 мс

Исполнение меньше чем за 1 с

Как можно быстрее

Как можно быстрее

Ограничения по времени

Прерывание малых тестов после 1 минуты

Прерывание средних тестов после 5 минут

Прерывание больших тестов после 15 минут

Прерывание огромных тестов после 1 часа

Таблица 2.1. Цели и ограничения времени отработки тестов по их размеру

Ресурс

Большие

Средние

Малые

Сетевые службы (открытие сокета)

Да

Только localhost

Подставные объекты

База данных

Да

Да

Подставные объекты

Доступ к файловой системе

Да

Да

Подставные объекты

Доступ к пользовательским системам

Да

Нежелательно

Подставные объекты

Вызов системных функций

Да

Нежелательно

Подставные объекты

Многопоточность

Да

Да

Нежелательно

Команды приостановки

Да

Да

Нет

Свойства системы

Да

Да

Нет

Таблица 2.2. Использование ресурсов в зависимости от размеров теста

Преимущества разных размеров тестов

Размер теста имеет значение. Он влияет на специфические преимущества теста. На рис. 2.5 показана общая сводка, а ниже мы приводим более подробный список достоинств и недостатков каждого типа тестов.

Рис. 2.5. Ограничения разных размеров тестов

Большие тесты

Достоинства и недостатки больших тестов:

— Большие тесты проверяют самое важное — работу приложения. Они учитывают поведение внешних подсистем.

— Большие тесты могут быть недетерминированными (результат может быть получен разными путями), потому что зависят от внешних подсистем.

— Большой охват усложняет поиск причин при неудачном прохождении теста.

— Подготовка данных для тестовых сценариев может занимать много времени.

— Из-за высокоуровневости больших тестов в них трудно прорабатывать граничные значения. Для этого нужны малые тесты.

Средние тесты

Достоинства и недостатки средних тестов:

— Требования к подставным объектам мягче, а временные ограничения свободнее, чем у малых тестов. Разработчики используют их как промежуточную ступень для перехода от больших тестов к малым.

— Средние тесты выполняются относительно быстро, поэтому разработчики могут запускать их часто.

— Средние тесты выполняются в стандартной среде разработки, поэтому их очень легко запускать.

— Средние тесты учитывают поведение внешних подсистем.

— Средние тесты могут быть недетерминированными, потому что зависят от внешних подсистем.

— Средние тесты выполняются не так быстро, как малые.

Малые тесты

Достоинства и недостатки малых тестов:

— Малые тесты помогают повысить чистоту кода, потому что работают узконаправленно с небольшими методами. Соблюдение требований подставных объектов приводит к хорошо структурированным интерфейсам между подсистемами.