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

// 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. Средние тесты охватывают несколько модулей и могут задействовать внешние источники данных