Как тестируют в Google
Шрифт:
Рис. 2.7. Пример зависимостей сборки
Мы видим, как два отдельных изменения в коде, находящихся на разных уровнях дерева зависимостей, анализируются, чтобы подобрать минимальный набор тестов, который определит, дать ли зеленый свет проектам Gmail и Buzz.
Сценарий 1: изменение в общей библиотеке
Для первого сценария возьмем изменение, которое модифицирует файлы в common_collections_util, как показано на
Рис. 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. Бейджи тест-сертификации показываются на вики-страницах проектов
Мы изобрели тест-сертификацию — это система заданий по тестированию, которые должна выполнить команда, чтобы стать сертифицированной. Все команды начинают с нулевого уровня. Если команда показывает мастерство базовой гигиены кода, ей дается первый уровень. Уровень команды постепенно растет с тем, как она учится писать все более чистый код. В игре в сертификацию всего пять уровней, как и во многих серьезных моделях зрелости разработки ПО.
Краткое описание уровней Тест-сертификации
Уровень 1
— Создать пакеты тестового покрытия.
— Установить систему непрерывной сборки.
— Ранжировать тесты на малые, средние и большие.
— Определить недетерминированные тесты.
— Создать набор смоук-тестов.
Уровень 2
— Не выпускать, пока не пройдут все тесты.
— Обязательно выполнять смоук-тесты до отправки кода.
— Инкрементальное покрытие всеми тестами не меньше 50%.
— Инкрементальное покрытие малыми тестами не меньше 10%.
— Хотя бы одна фича покрыта интеграционным тестом.
Уровень 3
— Создавать тесты для всех нетривиальных изменений
— Общее покрытие малыми тестами не меньше 50%.
— Важные новые фичи покрыты интеграционными тестами.
Уровень 4
— Смоук-тесты запускаются автоматически перед отправкой нового кода.
— Смоук-тесты проходят за время меньше 30 минут.
— Нет недетерминированных тестов.
— Общее тестовое покрытие не меньше 40%.
— Тестовое покрытие только малыми тестами не меньше 25%.
— Все важные фичи покрыты интеграционными тестами.
Уровень 5
— Добавить тест к исправлению всех нетривиальных багов.
— Активно использовать доступные средства анализа.
— Общее тестовое покрытие не меньше 60%.
— Тестовое покрытие только малыми тестами не меньше 40%.
Сначала мы обкатали программу на нескольких командах разработчиков, которые и так были позитивно настроены по отношению к тестированию. Они хотели улучшить свои навыки. Когда мы сбалансировали механизм наград, мы объявили открытым большое соревнование за бейджи по всей компании. Наша программа была принята на ура.
Продать нашу идею оказалось не так сложно, как казалось. Команды разработки только выигрывали от этого:
— Они получали поддержку от опытных тестировщиков, которые согласились стать наставниками тест-сертификации. Ресурсы тестирования всегда в дефиците, а присоединившись к программе, команда получала больше тестировщиков, чем ей было положено официально.
— Они получали помощь экспертов и учились лучше писать малые тесты.
— Они видели, какие команды лучше проводят тестирование, и понимали, у кого стоило учиться.