Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go

Привет! Меня зовут Сергей, я старший разработчик в Ozon и раньше вообще не был замечен в QA.

Все мы привыкли к лёгкому написанию тестов на Python и Java — это основные языки автотестировщиков с богатым инструментарием утилит и всего, что упрощает жизнь. Что нужно для написания автотестов для HTTP-сервиса на Python или Java? Гугл, бутылочка крафта и два часа времени. 

А как быть в случае с Go? Как раз на нём мы в большинстве случаев пишем микросервисы. И если тесты написаны на другом языке, разработчики не могут внести в них свой вклад или отревьюить их. Поэтому внутри Ozon активно развивается Go-сообщество QA, и этим ребятам тоже нужно тестировать HTTP-сервисы и проверять отчёты в Allure. Как настоящие сварщики мы подумали: «Если чего-то не хватает, нужно написать своё». Сказано — сделано: встречайте опенсорс-библиотеку CUTE в BDD-стиле, которая облегчает тяготы создания автотестов и упрощает переход на Go. Главные фичи: создание HTTP-тестов, возможность реализовывать проверки из коробки, Allure-отчёты и низкий порог входа.

Дисклеймер: Мои коллеги ранее уже рассказывали, как у нас тестируют на Go. Также не так давно мы писали про опенсорс-библиотеку Allure-Go. А сегодня речь пойдёт о библиотеке CUTE (Create Your Tests Easily).

Моя команда делает бэкенд для мобильного приложения, но к нам не ходят по gRPC, как это принято в Ozon. Подходящих инструментов для тестирования HTTP-сервисов внутри компании раньше не было, а те, что существовали вне, не подходили нам и не работали с Allure (что было важно).

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

Как было раньше?

Обычно тест состоит из следующих шагов:

1. Подготовить HTTP-клиент.

2. Создать данные для теста.

3. Выполнить HTTP-запрос.

4. Убедиться, что запрос выполнился.

5. Считать ответ в структуру.

6. Начать проверять структуру.

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

Ранее на Хабре уже рассказывали, как писать тесты для HTTP-сервисов в связке с Allure (рекомендую к прочтению, чтобы сравнить сложность подходов).

Как будет?

Рассмотрим самый простой кейс, когда нужно сделать запрос и проверить пару полей:

import ( "context" "net/http" "testing" "time"  "github.com/ozontech/cute" "github.com/ozontech/cute/asserts/json" )  func TestExample(t *testing.T) { cute.NewTestBuilder(). Title("Title").             // Задаём название для теста Description("Description"). // Придумываем описание // Тут можно ещё добавить много разных тегов и лейблов, которые поддерживаются Allure Create(). RequestBuilder( // Создаём HTTP-запрос cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"), cute.WithMethod(http.MethodGet), ). ExpectExecuteTimeout(10*time.Second). // Указываем, что запрос должен выполниться за 10 секунд  ExpectStatus(http.StatusOK).          // Ожидаем, что ответ будет 200 (OK) AssertBody(                           // Задаём проверку JSON в response body по определённым полям json.Equal("$[0].email", "super@puper.biz"), json.Present("$[1].name"), ). ExecuteTest(context.Background(), t) } 

А если в тесте возникнут какие-то проблемы, то отчёт будет такой:

При этом мы поддержали все возможные теги и лейблы Allure.

Сейчас мы рассмотрели самый простой тест с минимальным количеством информации, проверок и без каких-либо дополнений.

Заинтересовались? Тогда давайте рассмотрим все возможности библиотеки.

Строим тест

Шаг 0. Начало начал

Всё с чего-то начинается. Наш тест начинается с подготовки сервиса, который в дальнейшем будет нам помогать создавать тесты cute.NewHTTPTestMakerSuite(opts ...Option)

testMaker := cute.NewHTTPTestMakerSuite(opts ...Option)

При инициализации testMaker вы можете указать базовые настройки для тестов, например HTTP-клиент, если это вам важно. А можете ничего не настраивать — и всё будет работать из коробки.

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

Далее необходимо инициализировать сам билдер, его уже нужно создавать для каждого теста, так как он содержит в себе всю информацию о тесте.

testBuilder := testMaker.NewTestBuilder()

Если вам не важны настройки, то вы можете использовать заготовленный билдер:

cute.NewTestBuilder()

Отлично, на этом шаг 0 закончен! И мы готовы приступать к созданию теста.

Шаг 1. Информируем всех

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

cute.NewTestBuilder(). Title("TestExample_Simple"). // Заголовок Tags("simple", "some_local_tag" ,"some_global_tag", "json"). // Теги для поиска Feature("some_feature"). // Фича Epic("some_epic"). // Эпик Description("some_description"). // Описание теста

В примере выше указаны не все лейблы, со всеми остальными вы можете познакомиться внутри проекта.

Теперь информация о тесте появится у нас в отчётах.

Шаг 2. Помни о прошлом, не забывай о будущем

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

Вы можете это сделать вне теста, но также предусмотрены методы для упрощения работы:

BeforeExecute(func(req *http.Request) error) AfterExecute(func(resp *http.Response, errs []error) error)

Данные методы не обязательны, поэтому вы можете их пропустить.

Пример:

cute.NewTestBuilder(). Create(). BeforeExecute(func(req *http.Request) error { /* Необходимо добавить реализацию */ return nil }). AfterExecute(func(resp *http.Response, errs []error) error { /* Необходимо добавить реализацию */ return nil })

Ещё есть AfterExecuteT и BeforeExecuteT, которые позволяют добавить информацию в Allure, например создать новый шаг:

func BeforeExample(t cute.T, req *http.Request) error { t.WithNewStep("insideBefore", func(stepCtx provider.StepCtx) { now := time.Now() stepCtx.Logf("Test. Start time %v", now) stepCtx.WithNewParameters("Test. Start time", now) time.Sleep(2 * time.Second) })        return nil }

Allure:

Шаг 3. Создаем запрос

Существует два способа передать запрос в тесте.

Если у вас уже создан *http.Request, вы можете просто воспользоваться Request(*http.Request):

req, _ := http.NewRequest(http.MethodGet, "http://google.com", nil)  cute.NewTestBuilder(). Create(). Request(req) // Передача запроса 

Второй способ подойдёт, если у вас нет подготовленного запроса. Необходимо вызвать RequestBuilder и самостоятельно собрать запрос.

Выглядит это примерно так:

cute.NewTestBuilder(). Create(). RequestBuilder(  // Создание запроса  cute.WithHeaders(map[string][]string{  "some_header":       []string{"something"}, "some_array_header": []string{"1", "2", "3", "some_thing"}, }), cute.WithURI("http://google.com"),  cute.WithMethod(http.MethodGet),    )

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

Отлично, самое скучное позади! Мы заполнили информацию о тесте, подготовили дополнительные шаги и создали запрос — настало время проверок!

Шаг 4. Доверяй, но проверяй!

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

Response code

Начнём с элементарного — с проверки кода ответа. В этом нам поможет ExpectStatus(int).

Пример:

cute.NewTestBuilder(). Create(). Request(*http.Request). // Передача запроса  ExpectStatus(201) // Ожидаем, что ответ будет 201 (Created)

Allure:

JSON-схема

Перейдём к простому — к проверке JSON-схемы. Многим важно всегда иметь чёткую схему ответа.

Существует три способа проверить JSON-схему. Всё зависит от того, где она у вас находится.

1. ExpectJSONSchemaString(string) — получает и сравнивает JSON-схему из строки.

2. ExpectJSONSchemaByte([]byte) — получает и сравнивает JSON-схему из массива байтов.

3. ExpectJSONSchemaFile(string) — получает и сравнивает JSON-схему из файла или удалённого ресурса.

Пример:

cute.NewTestBuilder(). Create(). Request(*http.Request). // Передача запроса  ExpectJSONSchemaFile("file://./project/resources/schema.json"). // Проверка response body по JSON schema

В случае ошибки отчёт в Allure будет таким:

Отлично, самые простые проверки позади. Пора проверить наши запросы по-настоящему!

Шаг 5. Я сказал, нам нужны настоящие проверки!

Настало время создать настоящие ассерты и проверить полностью наш response.

В библиотеке есть подготовленные ассерты для проверки заголовков, для работы с JSON в теле ответа, но также вы можете создавать свои.

Существует три типа проверок:

1. Проверка тела ответа (response body)
   AssertBody и AssertBodyT

2. Проверка заголовков ответа (response headers)
   AssertHeaders и AssertHeadersT 

3. Полная проверка ответа (response)
   AssertResponse и AssertResponseT

Рассмотрим подробнее.

Проверка тела ответа (AssertBody)

Для проверок тела ответа в библиотеке есть несколько готовых решений.
Рассмотрим пример: допустим, нам надо из JSON достать поле “email” и убедиться, что значение равно “lol@arbidol.com”:

{   "email": "lol@arbidol.com" }

Для этого воспользуемся заготовленным ассертом из пакета:

cute.NewTestBuilder(). Create(). Request(*http.Request). // Передача запроса AssertBody(json.Equal("$.email", "lol@arbidol.com")) // Валидация поля “email” в response body

И это только один из примеров. В пакете есть целый набор ассертов:

• Contains

• Equal

• NotEqual

• Length

• GreaterThan

• LessThan

• Present

• NotPresent

В случае если ассерт не выполнился, в Allure появится красивый результат:

Проверка заголовков ответа (AssertHeaders)

С заголовками такая же история, как с телом ответа. Необходимо использовать:

AssertHeaders(func(headers http.Headers) error) AssertHeadersT(func(t cute.T, headers http.Headers) error)

Есть несколько готовых ассертов:

• Present

• NotPresent

Пример:

cute.NewTestBuilder(). Create(). Request(*http.Request). // Передача запроса    AssertHeaders(headers.Present("Content-Type")) // Проверка, что в заголовках есть “Content-Type” 

Полная проверка ответа (AssertResponse)

Когда необходимо проверить одновременно headers, body и ещё что-то из структуры http.Response, подойдёт:

   AssertResponse(func(resp *http.Response) error)    AssertResponseT(func(t cute.T, resp *http.Response) error)

Пример:

func CustomAssertResponse() cute.AssertResponse { return func(resp *http.Response) error { if resp.ContentLength == 0 { return errors.New("content length is zero") }   return nil } }

Шаг 6. Хочу быть самостоятельным!

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

Для этого необходимо создать функцию, которая будет реализовывать один из типов:

• type AssertBody func(body []byte) error

• type AssertHeaders func(headers http.Header) error

• type AssertResponse func(response *http.Response) error

• type AssertBodyT func(t cute.T, body []byte) error

• type AssertHeadersT func(t cute.T, headers http.Header) error

• type AssertResponseT func(t cute.T, response *http.Response) error

Пример:

func customAssertHeaders() cute.AssertHeaders { return func(headers http.Header) error { if len(headers) == 0 { return errors.New("response without headers") }   return nil } }

Ещё есть функции c cute.T, которые позволяют добавить информацию в Allure, например создать новый шаг:

func customAssertBody() cute.AssertBodyT {    return func(t cute.T, body []byte) error {        step := allure.NewSimpleStep("Custom assert step")        defer func() {            t.Step(step)        }()          if len(body) == 0 {            step.Status = allure.Failed            step.WithAttachments(allure.NewAttachment("Error", allure.Text, []byte("response body is empty")))              return nil        }          return nil } 

И далее просто добавляете свой ассерт в тест:

cute.NewTestBuilder(). Create(). Request(*http.Request). // Передача запроса AssertHeaders(customAssertHeaders). AssertBodyT(customAssertBody)

Custom error

Вы могли заметить, что в результатах заготовленных ассертов существуют набор полей: Name, Error, Action и Expected.

Чтобы добавить такие данные в ваши кастомные ассерты, вы можете использовать:

cuteErrors.NewAssertError(name string, err string, actual interface{}, expected interface{}) error

Пример:

import (    cuteErrors "github.com/ozontech/cute/errors" )   func customErrorExample (t cute.T, headers http.Header) error {    return cuteErrors.NewAssertError("custom_assert", "example custom assert", "empty", "not empty")    // Пример создания красивой ошибки  } 

Соответственно, в Allure появится такая красота:

Optional asserts

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

import (    cuteErrors "github.com/ozontech/cute/errors" )  func customOptionalError(body []byte) error {     return cuteErrors.NewOptionalError(errors.New("some optional error from creator")) // Пример создания опциональной ошибки  } 

Шаг 7. Финал

Для создания самого теста нам нужно вызвать ExecuteTest(context.Context, testing.TB).

В ExecuteTest вы можете передать обычный testing.T или provider.T. Если вы используете allure-go, это не имеет значения — всё равно будет создан отчёт.

В итоге, если соединить все шаги, у нас получится такой пример:

import (    "context"    "errors"    "net/http"    "testing"    "time"      "github.com/ozontech/cute"    "github.com/ozontech/cute/asserts/headers"    "github.com/ozontech/cute/asserts/json" )   func TestExampleTest(t *testing.T) {     cute.NewTestBuilder().        Title("TestExample_OneStep").        Tags("one_step", "some_local_tag", "json").        Feature("some_feature").        Epic("some_epic").        Description("some_description").        CreateWithStep().        StepName("Example GET json request").        AfterExecuteT(func(t cute.T, resp *http.Response, errs []error) error {            if len(errs) != 0 {                return nil            }            /* Необходимо добавить реализацию */            return nil        },        ).        RequestBuilder(            cute.WithHeaders(map[string][]string{                "some_header":       []string{"something"},                "some_array_header": []string{"1", "2", "3", "some_thing"},            }),            cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"),            cute.WithMethod(http.MethodGet),        ).        ExpectExecuteTimeout(10*time.Second).        ExpectStatus(http.StatusOK).        AssertBody(            json.Equal("$[0].email", "Eliseo@gardner.biz"),            json.Present("$[1].name"),            json.NotPresent("$[1].some_not_present"),            json.GreaterThan("$", 3),            json.Length("$", 5),            json.LessThan("$", 100),            json.NotEqual("$[3].name", "kekekekeke"),              // Custom assert body            func(bytes []byte) error {                if len(bytes) == 0 {                    return errors.New("response body is empty")                }                  return nil            },        ).        AssertBodyT(            func(t cute.T, body []byte) error {                /* Здесь должна быть реализация с T */                return nil            },        ).        AssertHeaders(            headers.Present("Content-Type"),        ).        AssertResponse(            func(resp *http.Response) error {                if resp.ContentLength == 0 {                    return errors.New("content length is zero")                }                  return nil            },        ).        ExecuteTest(context.Background(), t) } 

Allure:

Милый, принеси нам итоги, мы дочитали статью

В Go активно развивается культура тестирования. Не многие компании готовы к экспериментам — пробовать Go в QA. Мы в Ozon пошли на это и не пожалели: удобно, когда разработчики и тестировщики общаются на одном языке и разработчик может отревьюить или поправить автотесты. 

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

---

Если вас заинтересовало QA на Go, приходите на наш бесплатный курс «Автоматическое тестирование веб-сервисов на Go» — это 52 часа теории и практики от экспертов Ozon. Следующий набор стартует в августе.