Джеймс Уиттакер - Как тестируют в Google

По идее, при такой огромной и динамичной базе кода команды должны тратить кучу времени только на поддержание сборки в состоянии «зеленого света». Система непрерывной интеграции должна помогать с этим. Она должна сразу выделять изменение, приводящее к сбою теста, а не просто указывать на набор подозрительных изменений или, что еще хуже, перебирать их все в поисках нарушителя.

Чтобы решить эту проблему, мы построили систему непрерывной сборки (рис. 2.6), которая анализирует зависимости и выделяет только те тесты, которые связаны с конкретным изменением, а потом выполняет только их. И так для каждого изменения. Система построена на инфраструктуре облачных вычислений Google, которая позволяет одновременно выполнять большое количество сборок и запускать затронутые тесты сразу же после отправки изменений.

Примером ниже мы показываем, как наша система дает более быструю и точную обратную связь, чем типичная непрерывная сборка. В нашем сценарии используются два теста и три изменения, затрагивающие эти тесты. Тест gmail_server_tests падает из-за изменения 2. Типичная система непрерывной сборки сообщила бы, что к сбой случился из-за изменения 2 или 3, не уточняя. Мы же используем механизм параллельного выполнения, поэтому запускаем тесты независимо, не дожидаясь завершения текущего цикла «сборка–тестирование». Анализ зависимостей сузит набор тестов для каждого изменения, поэтому в нашем примере общее количество выполнений теста то же самое.

Рис. 2.6. Сравнение систем непрерывной интеграции

Наша система берет данные о зависимостях из спецификаций сборки, которые описывают, как компилируется код и какие файлы входят в сборку приложения и теста. Правила сборки имеют четкие входные и выходные данные, объединив которые получим точное описание процесса сборки. Наша система строит в памяти график зависимостей сборки, как на рис. 2.7, и обновляет его с каждым новым изменением. На основании этой схемы мы определяем все тесты, связанные прямо или косвенно с кодом, вошедшим в изменение. Именно эти тесты нужно запустить, чтобы узнать текущее состояние сборки. Давайте посмотрим на пример.

Рис. 2.7. Пример зависимостей сборки

Мы видим, как два отдельных изменения в коде, находящихся на разных уровнях дерева зависимостей, анализируются, чтобы подобрать минимальный набор тестов, который определит, дать ли зеленый свет проектам Gmail и Buzz.

Сценарий 1: изменение в общей библиотеке

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

Рис. 2.8. Изменение в common_collections_util.h

Отправив изменение, мы перемещаемся по линиям зависимостей вверх по графику. Так мы найдем все тесты, зависящие от изменений. Когда поиск завершится, а это займет лишь доли секунды, у нас будут все тесты, которые нужно прогнать, и мы получим актуальные статусы наших проектов (рис. 2.9).

Рис. 2.9. Тесты, на которые влияет изменение

Сценарий 2: изменение в зависимом проекте

Во втором примере возьмем изменение, которое модифицирует файлы в youtube_client (рис. 2.10).

Рис. 2.10. Изменение в youtube_client

Проведя аналогичный анализ, мы определим, что изменение влияет только на buzz_client_tests и что нужно актуализировать статус проекта Buzz (рис. 2.11).

Рис. 2.11. Buzz нужно обновить

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

Умные инструменты и возможности инфраструктуры облачных вычислений сделали систему непрерывной интеграции быстрой и надежной. И мы постоянно стараемся ее улучшить, хотя она уже используется в тысячах проектов Google, чтобы выпускать проекты быстрее и проводить больше итераций. И — что важно — наш прогресс замечают пользователи.

В начале книги Патрик Коупленд замечает, как сложно было привлечь разработчиков к тестированию. Первым делом мы создали им отличную компанию и наняли технически подкованных тестировщиков. А чтобы втянуть разработчиков в процесс, мы придумали «Тест-сертификацию». Оглядываясь назад, можно сказать, эта программа сыграла важную роль в становлении культуры тестирования разработчиками в Google.

Тест-сертификация начиналась как соревнование. Будут ли разработчики серьезно относиться к тестированию, если мы сделаем эту работу престижной? Что, если награждать разработчиков, которые следуют тестовым практикам? А что, если мы скажем, что они теперь сертифицированные инженеры? А может, еще ввести систему наградных бейджей (рис. 2.12), которыми можно пощеголять перед коллегами?

Рис. 2.12. Бейджи тест-сертификации показываются на вики-страницах проектов

Мы изобрели тест-сертификацию — это система заданий по тестированию, которые должна выполнить команда, чтобы стать сертифицированной. Все команды начинают с нулевого уровня. Если команда показывает мастерство базовой гигиены кода, ей дается первый уровень. Уровень команды постепенно растет с тем, как она учится писать все более чистый код. В игре в сертификацию всего пять уровней, как и во многих серьезных моделях зрелости разработки ПО.

Краткое описание уровней Тест-сертификации

Уровень 1

— Создать пакеты тестового покрытия.

— Установить систему непрерывной сборки.

— Ранжировать тесты на малые, средние и большие.

— Определить недетерминированные тесты.

— Создать набор смоук-тестов.

Уровень 2

— Не выпускать, пока не пройдут все тесты.

— Обязательно выполнять смоук-тесты до отправки кода.

— Инкрементальное покрытие всеми тестами не меньше 50%.

— Инкрементальное покрытие малыми тестами не меньше 10%.