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

– Тестирование. Насколько тестопригодна система, описанная в документе? Нужно ли будет встраивать в код новые зацепки для тестирования? Если да, проследите за тем, чтобы это добавили в документацию. Можно ли скорректировать структуру системы для упрощения тестирования или использования готовой тестовой инфраструктуры? Оцените, что нужно сделать для тестирования системы, и договоритесь с разработчиками, чтобы эту информацию добавили.

На заметку

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

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

Интерфейсы и протоколы

С описанием интерфейсов и протоколов разработчики Google справляются легко, ведь для этого нужно писать их любимый код. В Google разработали специальный расширяемый язык Protocol Buffer[19 - Protocol Buffer Google имеет открытую спецификацию, которая представлена тут: http://code.google.com/apis/protocolbuffers/] для сериализации структурированных данных. Protobuf – это механизм описания данных, который не зависит от языка программирования или платформы, которые вы собираетесь использовать. По сути, он похож на XML, только компактнее, быстрее и проще. Разработчик определяет структуру данных с помощью Protocol Buffer и потом использует сгенерированные исходники для чтения и записи структурированных данных на разных языках (Java, C++ или Python). Часто код Protocol Buffer становится первым написанным кодом в проекте. Можно встретить документацию, которая ссылается на protobuf-файлы при описании того, как должна работать полностью реализованная система.

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

На заметку

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

Планирование автоматизации

Время разработчика в тестировании ограничено и расписано по минутам, поэтому хорошая идея – создавать план автоматизации как можно раньше. План должен быть реалистичным. Пытаться автоматизировать все сразу в одном тестовом пакете – это ошибка. У разработчиков такие наполеоновские планы обычно не вызывают восторга, и они не спешат помогать. Если разработчик в тестировании хочет заручиться поддержкой разработчика, план автоматизации должен быть простым, четким и способным повлиять на проект. Тяжело поддерживать масштабную автоматизацию, которая с ростом системы расшатывается еще больше. Разработчиков можно привлечь писать только узконаправленные автотесты, которые приносят пользу с самого начала.

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

На заметку

Не стоит слишком рано вкладываться в сквозную автоматизацию – она привязывает вас к конкретной архитектуре проекта.

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

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

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

Тестируемость

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

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

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

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

На заметку

Google строит процесс разработки вокруг код-ревью. О том, как рецензировать код, говорят даже больше, чем о том, как его писать.

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

Когда код написан, он упаковывается в пакет, который мы называем списком изменений. Дальше он отправляется для рецензирования в приложение, которое в Google называют Mondrian, в честь голландского художника, положившего начало абстрактному искусству. Mondrian отсылает код ответственному разработчику или разработчику в тестировании для окончательного утверждения[20 - Версия Mondrian с открытым кодом на базе App Engine доступна по адресу: http://code.google.com/p/rietveld/].

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

Новички рано или поздно получают от коллег бейдж «спец по легкочитаемому коду», если постоянно коммитят качественные списки изменений. Эти бейджи – разные для разных языков программирования. Основные языки в Google – C++, Java, Python и JavaScript. Бейдж указывает нам опытного разработчика, который старается писать так, чтобы вся кодовая база однородной, будто ее писал один разработчик[21 - Руководство Google по стилю для C++ доступно по адресу: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml].

Прежде чем список изменений попадет к рецензенту, он пройдет ряд автоматических проверок в Mondrian. Программа проверит выполнение простых условий, например насколько код соответствует гайдлайнам стиля программирования Google, и более сложных, например что все тесты, связанные с этим списком изменений, проходят. Тесты для списка почти всегда включены прямо в него – тестовый и функциональный код живут вместе. Выполнив проверку, Mondrian отправит рецензенту по электронной почте ссылку на списки изменений. В свою очередь рецензент проанализирует код и выдаст рекомендации его автору. Процесс повторяется до тех пор, пока все рецензенты не будут довольны и автоматическая проверка не будет проходить гладко.

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

Очередь на отправку позволяет участникам больших команд совместно работать в ветке main дерева исходного кода. Больше не нужно замораживать код на время интеграции веток и прохождения тестов. Получается, что разработчики больших команд могут работать так же эффективно и независимо, как если бы команда была маленькая и гибкая. Только у разработчика в тестировании прибавляется работы – ведь скорость написания и заливки кода в репозиторий увеличивается.

Как появились очереди на отправку и непрерывная сборка

Джефф Карролло

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

Компания росла. Чтобы масштабироваться, наши разработчики писали и поддерживали качественные библиотеки и инфраструктуру, которые использовали все команды. Со временем росло количество, размеры и сложность базовых библиотек. Код проектов стал интенсивно использовать сторонние библиотеки и инфраструктуру, и одних юнит-тестов стало недостаточно – уже требовалось интеграционное тестирование. В какой-то момент стало понятно, что многие баги вызывались зависимостями между компонентами. Так как тесты не запускались до тех пор, пока кому-нибудь не вздумывалось закоммитить изменение в своем проекте, интеграционные баги могли оставаться незамеченными по несколько дней.

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

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

Система быстро стала популярной, и вскоре большинство проектов в Google перешло на нее. Если тест не проходил, то программа оповещала всех ответственных за изменение по почте. О сбоях стали узнавать через несколько минут после коммита изменений в базу кода. Кроме того, система отмечала «Золотые списки изменений» – контрольные точки в системе контроля версий, в которых успешно проходили все тесты проекта. Теперь разработчики могли ориентироваться на стабильную версию исходников без недавних проблемных изменений. Это очень помогало при выборе стабильной сборки для выпуска.

Но и этого инструмента инженерам оказалось недостаточно. Команды становились больше, проекты – сложнее, потери от поломанных сборок росли. Разработчики строили новые очереди отправок, чтобы защитить системы непрерывной сборки. В ранних реализациях все списки изменений действительно вставали в очередь: система тестировала и одобряла или отклоняла списки последовательно. Если нужно было провести много продолжительных тестов подряд, то между постановкой списка изменений в очередь и его фактической передачей в систему контроля версий могло пройти несколько часов. В следующих версиях уже реализовали параллельное выполнение ожидающих списков изменений, но они запускались изолированно друг от друга. Хотя это могло создавать проблемы нарушения последовательности потоков, такие случаи были редки, их оперативно обнаруживала система непрерывной сборки. Возможность заливки кода через несколько минут после отправки запроса экономила много времени. Это компенсировало затраты на исправление редких падений системы непрерывной сборки.

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

Эти две системы, панель мониторинга юнит-тестов и система непрерывной сборки Криса и Джея, использовались в Google несколько лет. Они принесли огромную пользу командам, были несложны в настройке и неприхотливы в сопровождении. И вот встал вопрос о реализации этих систем в виде общей инфраструктуры для всех команд. Так появилась система Test Automation Program (TAP). Когда мы писали эту книгу, TAP уже заменила собой обе первоначальные системы. Ее используют почти все проекты Google, кроме Chromium и Android. Только проекты с открытым кодом используют отдельные деревья исходного кода и серверные среды сборки.

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

Пример работы разработчика в тестировании

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

Представьте простое веб-приложение, с помощью которого пользователи отправляют URL-адреса в Google для добавления в Google-индекс. Форма HTML содержит два поля – ULR-адрес и комментарий – и генерирует запрос HTTP GET к серверу Google в следующем формате:

GET /addurl?url=http://www.foo.com&comment=Foo+comment HTTP/1.1

На стороне сервера это веб-приложение делится на две части: AddUrlFrontend, который получает запрос HTTP, распознает и проверяет его, и бэкенд AddUrlService. Сервис бэкенда получает запросы от AddUrlFrontend, проверяет, нет ли в них ошибок, и дальше взаимодействует с такими хранилищами данных, как, например, Google Bigtable[22 - http://labs.google.com/papers/bigtable.html] или Google File System[23 - http://labs.google.com/papers/gfs.html].

Разработчик начинает работу с создания каталога для проекта:

$ mkdir depot/addurl/

Затем он определяет протокол AddUrlService с использованием языка Protocol Buffers[24 - http://code.google.com/apis/protocolbuffers/docs/overview.html]: