Как тестируют в Google - Уиттакер Джеймс, Арбон Джейсон, Каролло Джефф (2014)

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

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

GET /addurl?url= 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.

}