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

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

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

На заметку

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

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

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

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

На заметку

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

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

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

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

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