Как тестируют в Google. Глава 2. Разработчик в тестировании (Д. А. Уиттакер, 2012)

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

Другие тесты требуют знаний, выходящих за рамки кода, и зависят от внешней инфраструктуры. Например, у нас есть тест, который возвращает данные из удаленного хранилища (с сервера баз данных или из облака). Для тестирования нам нужна либо сама база данных, либо ее имитация. В индустрии уже выработались инструменты для этого: тестовая оснастка (harness), тестовая инфраструктура, подставные объекты (mocks) и имитации (fakes). В мире идеального процесса разработки эти макеты сразу существуют для любого интерфейса, с которым имеет дело разработчик, и каждый аспект любой функции можно протестировать в любое время. Но не увлекайтесь, мы находимся в воображаемом мире.

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

На заметку

При написании кода функциональности и кода тестов важны разные образы мышления.

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

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

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

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

Кто хочет работать в компании, в которой программные продукты создаются подобным образом? Мы точно хотим!

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

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

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

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

Это уже не сказка, а наша попытка сделать ее былью.

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

Жизнь разработчика в тестировании

Когда компания только появляется, тестировщиков в ней, как правило, нет. Точно так же как нет руководителей проектов, системных администраторов и других должностей. Каждый сотрудник выполняет все эти роли одновременно. Мы любим представлять, как Ларри и Сергей[14] ломали головы над пользовательскими сценариями и юнит-тестами на заре Google. С ростом компании появились разработчики в тестировании, которые первыми привнесли фокус на качество в строго технологический дух программирования[15]

Как организованы процессы разработки и тестирования

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

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

На заметку

Готовый код – основной артефакт, над которым работают все участники команды. Организовать структуру, написать код и сопровождать его – их ежедневные задачи.

Еще один плюс единого репозитория: инженерам, переходящим из проекта в проект, не нужно переучиваться, а так называемые «двадцатипроцентные сотрудники» могут нормально работать с первого дня в проекте[16]. Кроме того, весь исходный код доступен любому инженеру. Разработчики веб-приложений могут просмотреть интересующий их код браузера, не спрашивая ни у кого разрешения, или узнать, как другие, более опытные сотрудники решали аналогичные задачи. Можно взять код для повторного использования на уровне модулей или даже на уровне структур контролов или данных. Google – един, и он использует общий репозиторий с удобными (еще бы!) средствами поиска.

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

На заметку

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

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

– Используйте уже написанные библиотеки по максимуму. Пишите свою только в том случае, если у вас есть на то серьезная причина из-за специфических особенностей проекта.

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

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

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

Если инженер предлагает более удачное решение, то он же проводит рефакторинг всех существующих библиотек и помогает перевести все зависимые проекты на новые библиотеки. Работа на благо сообщества должна поощряться[17].

Google серьезно относится к процедуре код-ревью, и любой код, особенно общий, просматривает специалист с черным поясом по читаемости кода. Специальная комиссия выделяет таких специалистов за умение писать чистый и стилистически точный код для четырех основных языков Google (C++, Java, Python и JavaScript).

Код в общем репозитории устанавливает более высокую планку для тестирования, – об этом мы расскажем чуть позже.

Для решения проблем с зависимостями платформ мы минимизируем их различия на машинах сотрудников. У всех инженеров на компьютерах стоит та же версия OS, что и на боевых машинах. Мы тщательно следим за актуальностью сборок Linux, чтобы разработчик, проводящий тестирование на своем компьютере, получил такие же результаты, как и при тестировании в боевой среде. Различия в процессорах и операционных системах между компьютерами инженеров и дата-центрами минимальны[18]. Если баг возник на компьютере тестировщика, то он, скорее всего, воспроизведется и на компьютере разработчика, и в условиях реальной эксплуатации.

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

На заметку

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

Тему единообразия платформ и единства репозитория продолжает единая система сборки, не зависящая от языка, на котором написан проект. Не важно, на каком языке работает команда (C++, Python или Java), она все равно будет использовать общие «файлы сборки».

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

Последовательность шагов следующая.

1. Напишите класс или набор функций в одном или нескольких исходных файлах. Убедитесь, что весь код компилируется.

2. Укажите цель сборки (например, определенную библиотеку) для новой сборки.

3. Напишите юнит-тесты, которые импортируют библиотеку, имитируют нетривиальные зависимости и выполняют интересующие нас пути в коде для самых актуальных входных данных.

4. Создайте тестовую сборку для юнит-тестов.

5. Соберите и запустите сборку с тестами. Изменяйте код до тех пор, пока все тесты не будут проходить.

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

7. Отправьте итоговый код на код-ревью (подробнее о код-ревью мы расскажем позже), внесите изменения и повторите все юнит-тесты.

В результате мы создаем две сборки: собственно библиотеку, представляющую новый сервис, и сборку тестов для этого сервиса. Учтите, что многие разработчики в Google применяют методологию TDD (Test-Driven Development, или разработка через тестирование), при которой шаг 3 предшествует шагам 1 и 2.

Если разработчик конструирует более крупный сервис, то он продолжает писать код, связывая постоянно увеличивающиеся сборки библиотек. Сборка бинарника создается из основного файла, который ссылается на нужные библиотеки. Так появляется продукт Google, у которого есть:

– хорошо протестированный автономный бинарный файл;

– легкочитаемая и приспособленная для повторного использования библиотека (с набором вспомогательных библиотек, которые можно использовать для создания других сервисов);

– набор юнит-тестов, покрывающих нужные аспекты всех сборок.

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

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

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

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

Кто такие разработчики в тестировании на самом деле?

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

На заметку

Тест – это еще одна фича приложения, и за нее отвечают разработчики в тестировании.

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

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

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

Ранняя стадия проекта

В Google нет правила, когда именно разработчики в тестировании должны присоединиться к проекту. Так же как нигде не прописано, когда именно проект становится «реальным». Типичный сценарий создания нового проекта такой: эксперимент, над которым работали в «двадцатипроцентное» время, набирается сил и становится самостоятельным продуктом Google. Именно так развивались Gmail и Chrome OS. Эти проекты начинались с неформальных идей, а со временем выросли в полноценные продукты со своими командами разработчиков и тестировщиков. Наш друг Альберто Савоя (написавший введение к этой книге) любит повторять, что «качество не имеет значения, пока ваш продукт не имеет значения».

В свое «двадцатипроцентное» время команды придумывают много нового. Часть этих идей ни к чему не приведет, другая часть станет новыми фичами других проектов, а некоторые смогут перерасти в официальные продукты Google. Ни одному проекту по умолчанию не полагается тестирование. Проект может потерпеть неудачу, поэтому включать в него тестировщиков – напрасная трата ресурсов. Если проект закроют, что мы будем делать с готовой тестовой инфраструктурой?

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

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

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

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

Все это – особая культура Google. Ни один проект не получит ресурсы тестирования просто так. Команды разработки обращаются к тестировщикам за помощью, убеждая их в том, что проект по-настоящему интересен и перспективен. После того как руководители разработки Chrome OS обрисовали свой проект, состояние дел и график выпуска, мы смогли выдвинуть свои требования по участию разработчиков в тестировании, уровню покрытия кода юнит-тестами и разделению обязанностей в процессе работы. Мы не участвовали в зарождении проекта, но когда он стал реальным, мы смогли серьезно повлиять на его реализацию.

На заметку

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

Структура команды

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

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

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

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

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

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

Проектная документация

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

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

На заметку

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

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

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

– Чем раньше внесено предложение, тем больше вероятность, что оно попадет в документ, а потом и в код. Так разработчика в тестировании сможет сильнее повлиять на проект.

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

– Это прекрасный шанс установить рабочие отношения со всеми инженерами, с чьим кодом разработчик в тестировании будет работать, когда начнется разработка.

Проектную документацию нужно рецензировать целенаправленно и вдумчиво, а не бегло просматривать, как утреннюю газету. Хороший разработчик в тестировании, оценивая документ, преследует четкие цели. Вот что советуем мы:

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

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

– Согласованность. Убедитесь в том, что текст соответствует диаграммам. Проследите, чтобы документ не противоречил утверждениям, сделанным в других документах.

– Архитектура. Проанализируйте архитектуру, предложенную в документе. Можно ли ее реализовать с доступными ресурсами? Какая инфраструктура будет использоваться? Прочитайте описание этой инфраструктуры и изучите ее подводные камни. Можем ли мы поддерживать предложенную инфраструктуру в нашей системе? Архитектура не слишком сложная? Можно ее упростить? Не слишком ли она проста? Что еще нужно учесть при работе с этой архитектурой?

– Интерфейсы и протоколы. Четко ли в документе определены будущие протоколы? Полностью ли описаны интерфейсы и протоколы, которые будет предоставлять продукт? Соответствуют ли эти интерфейсы и протоколы своим целям? Соответствуют ли они стандартам продуктов Google? Можно ли рекомендовать разработчику пойти дальше и начать писать protobuf-файлы (эту концепцию мы опишем дальше)?

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

На заметку

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

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

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

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

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

На заметку

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

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

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

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

На заметку

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

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

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

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

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

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

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

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

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

На заметку

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

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

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

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

Новички рано или поздно получают от коллег бейдж «спец по легкочитаемому коду», если постоянно коммитят качественные списки изменений. Эти бейджи – разные для разных языков программирования. Основные языки в Google – C++, Java, Python и JavaScript. Бейдж указывает нам опытного разработчика, который старается писать так, чтобы вся кодовая база однородной, будто ее писал один разработчик[21].

Прежде чем список изменений попадет к рецензенту, он пройдет ряд автоматических проверок в 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] или Google File System[23].

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

$ mkdir depot/addurl/

Затем он определяет протокол AddUrlService с использованием языка Protocol Buffers[24]:

File: depot/addurl/addurl.proto

message AddUrlRequest {

required string url = 1; // The URL address entered by user.

optional string comment = 2; // Comments made by user.

}

message AddUrlReply {

// Error code if an error occured.

optional int32 error_code = 1;

// Error mtssage if an error occured.

optional string error_details = 2;

}

service AddUrlService {

// Accepts a URL for submission to the index.

rpc AddUrl(AddUrlRequest) returns (AddUrlReply) {

option deadline = 10.0;

}

}

В файле addurl.proto определены три важных элемента: сообщения AddUrlRequest и AddUrlReply и сервис удаленного вызова процедур (RPC, Remote Procedure) AddUrlService.

Посмотрев на определения сообщения AddUrlRequest, мы видим, что поле url должно быть задано вызывающей стороной, а поле comment не является обязательным.

Точно так же из определения сообщения AddUrlReply следует, что оба поля – error_code и error_details опционально могут быть переданы в ответах сервиса. Мы предполагаем, что в типичном случае, когда URL-адрес успешно принят, эти поля останутся пустыми, чтобы минимизировать объем передаваемых данных. Это одно из правил Google: типичный случай должен работать быстро.

Из определения AddUrlService видно, что сервис содержит единственный метод AddUrl, который принимает AddUrlRequest и возвращает AddUrlReply. По умолчанию вызов метода AddUrl прерывается по тайм-ауту через 10 секунд, если клиент не получил ответа за это время. Реализации интерфейса AddUrlService могут включать в себя сколько угодно систем хранения данных, но для клиентов интерфейса это несущественно, поэтому эти подробности не отражены в файле addurl.proto.

Обозначение '= 1' в полях сообщений не имеет никакого отношения к значениям этих полей. Оно существует для того, чтобы протокол можно было дорабатывать. Например, кто-то захочет добавить поле uri в сообщение AddUrlRequest к уже имеющимся полям. Для этого вносится следующее изменение:

message AddUrlRequest {

required string url = 1; // The URL entered by the user.

optional string comment = 2; // Comments made by the user.

optional string uri = 3; // The URI entered by the user.

}

Но это выглядит довольно глупо – скорее всего, потребуется просто переименовать поле url в uri. Если это число и тип останутся неизменными, сохранится совместимость между старой и новой версией:

message AddUrlRequest {

required string uri = 1; // The URI entered by user.

optional string comment = 2; // Comments made by the user.

}

Написав файл addurl.proto, разработчик переходит к созданию правила сборки proto_library, которое генерирует исходные файлы C++, определяющие сущности из addurl.proto, и компилирует их в статическую библиотеку addurl C++. С дополнительными параметрами можно сгенерировать исходный код для языков Java и Python.

File: depot/addurl/BUILD

proto_library(name="addurl",

srcs=["addurl.proto"])

Разработчик запускает систему сборки и исправляет все проблемы, обнаруженные ею в addurl.proto и в файле BUILD. Система сборки вызывает компилятор Protocol Buffers, генерирует исходные файлы addurl.pb.h и addurl.pb.cc и статическую библиотеку addurl, которую теперь можно подключить.

Пора писать AddUrlFrontend. Для этого мы объявляем класс AddUrlFrontend в новом файле addurl_frontend.h. Этот код в основном шаблонный.

File: depot/addurl/addurl_frontend.h

#ifndef ADDURL_ADDURL_FRONTEND_H_

#define ADDURL_ADDURL_FRONTEND_H_

// Forward-declaration of dependencies.

class AddUrlService;

class HTTPRequest;

class HTTPReply;

// Frontend for the AddUrl system.

// Accepts HTTP requests from web clients,

// and forwards well-formed requests to the backend.

class AddUrlFrontend {

public:

// Constructor which enables injection of an

// AddUrlService dependency.

explicit AddUrlFrontend(AddUrlService* add_url_service);

~AddUrlFrontend();

// Method invoked by our HTTP server when a request arrives

// for the /addurl resource.

void HandleAddUrlFrontendRequest(const HTTPRequest* http_request,

HTTPReply* http_reply);

private:

AddUrlService* add_url_service_;

// Declare copy constructor and operator= private to prohibit

// unintentional copying of instances of this class.

AddUrlFrontend(const AddUrlFrontend&);

AddUrlFrontend& operator=(const AddUrlFrontend& rhs);

};

#endif // ADDURL_ADDURL_FRONTEND_H_

Продолжая определять классы AddUrlFrontend, разработчик создает файл addurl_frontend.cc, в котором описывает класс AddUrlFrontend. Для экономии места мы опустили часть файла.

File: depot/addurl/addurl_frontend.cc

#include "addurl/addurl_frontend.h"

#include "addurl/addurl.pb.h"

#include "path/to/httpqueryparams.h"

// Functions used by HandleAddUrlFrontendRequest() below, but

// whose definitions are omitted for brevity.

void ExtractHttpQueryParams(const HTTPRequest* http_request,

HTTPQueryParams* query_params);

void WriteHttp200Reply(HTTPReply* reply);

void WriteHttpReplyWithErrorDetails(

HTTPReply* http_reply, const AddUrlReply& add_url_reply);

// AddUrlFrontend constructor that injects the AddUrlService

// dependency.

AddUrlFrontend::AddUrlFrontend(AddUrlService* add_url_service)

: add_url_service_(add_url_service) {

}

// AddUrlFrontend destructor – there's nothing to do here.

AddUrlFrontend::~AddUrlFrontend() {

}

// HandleAddUrlFrontendRequest:

// Handles requests to /addurl by parsing the request,

// dispatching a backend request to an AddUrlService backend,

// and transforming the backend reply into an appropriate

// HTTP reply.

//

// Args:

// http_request – The raw HTTP request received by the server.

// http_reply – The raw HTTP reply to send in response.

void AddUrlFrontend::HandleAddUrlFrontendRequest(

const HTTPRequest* http_request, HTTPReply* http_reply) {

// Extract the query parameters from the raw HTTP request.

HTTPQueryParams query_params;

ExtractHttpQueryParams(http_request, &query_params);

// Get the 'url' and 'comment' query components.

// Default each to an empty string if they were not present

// in http_request.

string url =

query_params.GetQueryComponentDefault("url", "");

string comment =

query_params.GetQueryComponentDefault("comment", "");

// Prepare the request to the AddUrlService backend.

AddUrlRequest add_url_request;

AddUrlReply add_url_reply;

add_url_request.set_url(url);

if (!comment.empty()) {

add_url_request.set_comment(comment);

}

// Issue the request to the AddUrlService backend.

RPC rpc;

add_url_service_->AddUrl(

&rpc, &add_url_request, &add_url_reply);

// Block until the reply is received from the

// AddUrlService backend.

rpc.Wait();

// Handle errors, if any:

if (add_url_reply.has_error_code()) {

WriteHttpReplyWithErrorDetails(http_reply, add_url_reply);

} else {

// No errors. Send HTTP 200 OK response to client.

WriteHttp200Reply(http_reply);

}

}

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

В этом месте разработчик изменяет существующую спецификацию сборки проекта addurl, включая в нее запись для библиотеки addurl_frontend. При сборке создается статическая библиотека C++ для AddUrlFrontend.

File: /depot/addurl/BUILD

# From before:

proto_library(name="addurl",

srcs=["addurl.proto"])

# New:

cc_library(name="addurl_frontend",

srcs=["addurl_frontend.cc"],

deps=[

"path/to/httpqueryparams",

"other_http_server_stuff",

":addurl", # Link against the addurl library above.

])

Разработчик снова запускает средства сборки, исправляет ошибки компиляции и компоновщика в addurl_frontend.h и addurl_frontend.cc, пока все не будет собираться и компоноваться без предупреждений или ошибок. На этой стадии пора писать юнит-тесты для AddUrlFrontend. Они пишутся в новом файле addurl_frontend_test.cc. Тест определяет имитацию для бэкенд-системы AddUrlService и использует конструктор AddUrlFrontend для внедрения этой имитации во время тестирования. При таком подходе разработчик может внедрять ожидания и ошибки в поток операций AddUrlFrontend без изменения кода AddUrlFrontend.

File: depot/addurl/addurl_frontend_test.cc

#include "addurl/addurl.pb.h"

#include "addurl/addurl_frontend.h"

// See http://code.google.com/p/googletest/

#include "path/to/googletest.h"

// Defines a fake AddUrlService, which will be injected by

// the AddUrlFrontendTest test fixture into AddUrlFrontend

// instances under test.

class FakeAddUrlService : public AddUrlService {

public:

FakeAddUrlService()

: has_request_expectations_(false),

error_code_(0) {

}

// Allows tests to set expectations on requests.

void set_expected_url(const string& url) {

expected_url_ = url;

has_request_expectations_ = true;

}

void set_expected_comment(const string& comment) {

expected_comment_ = comment;

has_request_expectations_ = true;

}

// Allows for injection of errors by tests.

void set_error_code(int error_code) {

error_code_ = error_code;

}

void set_error_details(const string& error_details) {

error_details_ = error_details;

}

// Overrides of the AddUrlService::AddUrl method generated from

// service definition in addurl.proto by the Protocol Buffer

// compiler.

virtual void AddUrl(RPC* rpc,

const AddUrlRequest* request,

AddUrlReply* reply) {

// Enforce expectations on request (if present).

if (has_request_expectations_) {

EXPECT_EQ(expected_url_, request->url());

EXPECT_EQ(expected_comment_, request->comment());

}

// Inject errors specified in the set_* methods above if present.

if (error_code_ != 0 || !error_details_.empty()) {

reply->set_error_code(error_code_);

reply->set_error_details(error_details_);

}

}

private:

// Expected request information.

// Clients set using set_expected_* methods.

string expected_url_;

string expected_comment_;

bool has_request_expectations_;

// Injected error information.

// Clients set using set_* methods above.

int error_code_;

string error_details_;

};

// The test fixture for AddUrlFrontend. It is code shared by the

// TEST_F test definitions below. For every test using this

// fixture, the fixture will create a FakeAddUrlService, an

// AddUrlFrontend, and inject the FakeAddUrlService into that

// AddUrlFrontend. Tests will have access to both of these

// objects at runtime.

class AddurlFrontendTest : public ::testing::Test {

// Runs before every test method is executed.

virtual void SetUp() {

// Create a FakeAddUrlService for injection.

fake_add_url_service_.reset(new FakeAddUrlService);

// Create an AddUrlFrontend and inject our FakeAddUrlService

// into it.

add_url_frontend_.reset(

new AddUrlFrontend(fake_add_url_service_.get()));

}

scoped_ptr<FakeAddUrlService> fake_add_url_service_;

scoped_ptr<AddUrlFrontend> add_url_frontend_;

};

// Test that AddurlFrontendTest::SetUp works.

TEST_F(AddurlFrontendTest, FixtureTest) {

// AddurlFrontendTest::SetUp was invoked by this point.

}

// Test that AddUrlFrontend parses URLs correctly from its

// query parameters.

TEST_F(AddurlFrontendTest, ParsesUrlCorrectly) {

HTTPRequest http_request;

HTTPReply http_reply;

// Configure the request to go to the /addurl resource and

// to contain a 'url' query parameter.

http_request.set_text(

"GET /addurl?url=http://www.foo.com HTTP/1.1");

// Tell the FakeAddUrlService to expect to receive a URL

// of 'http://www.foo.com'.

fake_add_url_service_->set_expected_url("http://www.foo.com");

// Send the request to AddUrlFrontend, which should dispatch

// a request to the FakeAddUrlService.

add_url_frontend_->HandleAddUrlFrontendRequest(

&http_request, &http_reply);

// Validate the response.

EXPECT_STREQ("200 OK", http_reply.text());

}

// Test that AddUrlFrontend parses comments correctly from its

// query parameters.

TEST_F(AddurlFrontendTest, ParsesCommentCorrectly) {

HTTPRequest http_request;

HTTPReply http_reply;

// Configure the request to go to the /addurl resource and

// to contain a 'url' query parameter and to also contain

// a 'comment' query parameter that contains the

// url-encoded query string 'Test comment'.

http_request.set_text("GET /addurl?url=http://www.foo.com"

"&comment=Test+comment HTTP/1.1");

// Tell the FakeAddUrlService to expect to receive a URL

// of 'http://www.foo.com' again.

fake_add_url_service_->set_expected_url("http://www.foo.com");

// Tell the FakeAddUrlService to also expect to receive a

// comment of 'Test comment' this time.

fake_add_url_service_->set_expected_comment("Test comment");

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

Знатоки гибкой методологии тестирования укажут, что все функции FakeAddUrlService достаточно просты и вместо имитации (fake) можно было бы использовать подставной объект (mock). И они будут правы. Мы реализовали эти функции в виде имитации исключительно для ознакомления с процессом.

Теперь разработчик хочет выполнить написанные тесты. Для этого он должен обновить свои определения сборки и включить новое тестовое правило, определяющее бинарник теста addurl_frontend_test.

File: depot/addurl/BUILD

# From before:

proto_library(name="addurl",

srcs=["addurl.proto"])

# Also from before:

cc_library(name="addurl_frontend",

srcs=["addurl_frontend.cc"],

deps=[

"path/to/httpqueryparams",

"other_http_server_stuff",

":addurl", # Depends on the proto_library above.

])

# New:

cc_test(name="addurl_frontend_test",

size="small", # See section on Test Sizes.

srcs=["addurl_frontend_test.cc"],

deps=[

":addurl_frontend", # Depends on library above.

"path/to/googletest_main"])

И снова разработчик использует свои инструменты сборки для компилирования и запуска бинарного файла addurl_frontend_test, исправляет все обнаруженные ошибки компилятора и компоновщика. Кроме того, он исправляет тесты, тестовые фикстуры, имитации и саму AddUrlFrontend по всем падениям тестов. Этот процесс начинается сразу же после определения FixtureTest и повторяется при следующих добавлениях тестовых сценариев. Когда все тесты готовы и успешно проходят, разработчик создает список изменений, содержащий все файлы, а заодно исправляет все мелкие проблемы, выявленные в ходе предварительных проверок. После этого он отправляет список изменений на рецензирование и переходит к следующей задаче (скорее всего, начинает писать реальный бэкенд AddUrlService), одновременно ожидая обратной связи от рецензента.

$ create_cl BUILD \par addurl.proto \par addurl_frontend.h \par addurl_frontend.cc \par addurl_frontend_test.cc

$ mail_cl -m reviewer@google.com

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

Выполнение тестов

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

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

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

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

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

Определения размеров тестов

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

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

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

Рис. 2.1. В Google используется много разных видов тестов

Рис. 2.2. В малом тесте обычно проверяется всего одна функция

Рис. 2.3. Средние тесты охватывают несколько модулей и могут задействовать внешние источники данных

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

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

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

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

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

На заметку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к выполнению тестов

У системы выполнения тестов в Google одинаковые требования ко всем тестам.

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

– Тесты не должны иметь долгосрочных последствий. После их завершения среда должна возвращаться в то же состояние, в котором она находилась при запуске.

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

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

– оба теста пытаются подключиться к одному порту для единоличного получения сетевого трафика;

– оба теста пытаются создать каталог, используя один путь;

– один тест создает и заполняет таблицу базы данных, а другой пытается удалить ту же таблицу.

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

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

– каждый тест запрашивает свободный порт у системы выполнения тестов, а тестируемая программа динамически к нему подключается;

– каждый тест создает все папки и файлы во временной директории, созданной и выделенной системой специально для него перед выполнением тестов;

– каждый тест работает со своим экземпляром базы данных в изолированной среде с выделенными системой выполнения тестов директориями и портами.

Ребята, ответственные за сопровождение системы выполнения тестов Google, довольно подробно описали свою среду выполнения тестов. Их документ называется «Энциклопедией тестирования Google», и он отвечает на все вопросы о том, какие ресурсы доступны тестам во время выполнения. «Энциклопедия тестирования» составлена как стандартизированный документ, где у терминов «должен» и «будет» однозначное значение. В энциклопедии подробно объясняются роли и обязанности тестов, исполнителей тестов, систем хостинга, рантайм-библиотек, файловых систем и т. д.

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

Тестирование на скоростях и в масштабах Google

Пуджа Гупта, Марк Айви и Джон Пеникс

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

1. Получить последнюю копию кода.

2. Выполнить все тесты.

3. Сообщить о результатах.

4. Перейти к пункту 1.

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

Разработка программных продуктов в Google происходит быстро и с размахом. Мы добавляем в базу кода всего Google больше 20 изменений в минуту, и 50 % файлов в ней меняются каждый месяц. Разработка и выпуск всех продуктов опираются на автотесты, проверяющие поведение продукта. Есть продукты, которые выпускаются несколько раз в день, другие – раз в несколько недель.

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

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

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

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

Конец ознакомительного фрагмента.