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

//  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\r\n\r\n");

   //  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\r\n\r\n");

   //  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. Такой тест поможет, если наш разработчик забыл проверить и обработать ситуацию с возникновением тайм-аута.

Знатоки гибкой методологии тестирования укажут, что все функции FakeAdd­UrlService достаточно просты и вместо имитации (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  \

                     addurl.proto  \

                     addurl_frontend.h  \