Home

Автор: Марк Уинтерингэм (Mark Winteringham)
Оригинал статьи
Перевод: Ольга Алифанова

В канале API-тестирования “Министерства тестирования” в Slack часто задают вопрос, как быть с автоматизаций проверок API для “негативных” сценариев (мне этот вопрос тоже задают нередко). При помощи технологий вроде HTTP можно быстро создавать комбинации запросов, и это иногда вызывает ошеломление, что же и как автоматизировать на уровне API.

Для помощи с решением начнем с углубления в вопрос, что же такое “негативный” сценарий. К примеру, у нас есть Web API с конечной точкой /validate, на которую отправляется емейл-адрес - там определяется, валиден ли он. Сырой HTTP-запрос будет выглядеть примерно так:

POST /validate HTTP/1.1
 Host: localhost:8080
 Content-Type: application/json
{
    "email": "
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 "
}

Мы решили проверить, насколько корректно ведет себя конечная точка, создав автоматическую проверку, отправляющую этот запрос и убеждающуюся в положительном ответе - нечто похожее на этот пример из Supertest:

request('http://localhost:8080')
    .post('/validate')
    .set('Content-Type', 'application/json')
    .send({
        "email": "
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 "
    })
    .expect(200)

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

Паттерны автоматизации негативных тестов API

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

request('http://localhost:8080')
    .post('/validate')
    .set('Content-Type', 'application/json')
    .send({
        "email": "test@examplecom"
    })
    .expect(400)

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

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

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

Пусть вами руководит риск

То, что мы можем что-то автоматизировать, не значит, что мы должны это делать. Один из принципов автоматизации в тестировании - это

Концентрация на риске, а не на покрытии

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

Ключ к ответу, стоит ли это автоматизировать, и ценны ли имеющиеся автоматизированные проверки - это вопрос

Какой риск я буду снижать?

Или

Какие риски снижены благодаря этим проверкам?

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

По сути способ внедрения автоматизации вторичен по отношению к сделанным выборам. Успешная автоматизация заставляет задавать вопрос, почему мы это автоматизируем. Если у нас есть веская причина - можно использовать техники вроде управления через данные для создания целого спектра автоматизированных проверок API с разными пермутациями, приносящего пользу. Но если ответ на этот вопрос отсутствует, то ответом на вопрос, нужно ли автоматизировать все негативные сценарии API, будет “Нет”, если это не принесет никакой пользы.

Обсудить в форуме