Привет! Я Владимир Пасюга, QA Engineer в NIX. Общий опыт в IT у меня составляет 7 лет, из них 2,5 года я был мануальным тестировщиком в биомедицинском проекте, который включал и UI, и API-часть. Сейчас занимаюсь автоматизированными тестами API в приложении для медицинской сферы.
В этой статье я хочу поделиться своим опытом тестирования API с помощью фреймворков Cucumber и Spock. Я расскажу, что представляет собой API и как проходит мануальное и автоматизированное тестирование этого интерфейса в нашей команде, опишу действенные инструменты и технологии и уделю особое внимание Cucumber и Spock.
Коротко о базовых понятиях
Чтобы предметно говорить о тестировании API, для начала освежим знания о базовых понятиях. API фактически позволяет независимым компонентам программного обеспечения обмениваться информацией. Иными словами API выступает посредником между внутренними и внешними программными функциями. Если программу рассматривать как черный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и дергать, как ему угодно.
На сегодняшний день существует два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API. Если сравнить HTTP-запрос с бумажным носителем, то можно сказать, что REST API в большинстве случаев передает простые записки и время от времени — письмо в конверте (возможно, написав при этом часть послания и на самом конверте). В свою очередь, SOAP API отправляет все инструкции в подробном письме стандартного вида, используя конверт (единичный HTTP-запрос) лишь как средство доставки.
Когда клиенты и серверы работают только в веб-среде, информация об объектах не важна и нет транзакций с несколькими вызовами, применяют REST API. Если же необходимо соблюсти строгий контракт между сервером и клиентом, обеспечить те самые транзакции с несколькими вызовами с высокой безопасностью и нет проблем с пропускной способностью, тогда микросервисы настраивают на SOAP API.
Какие инструменты нужны для тестирования API?
Отсутствие элементов UI-интерфейса с непривычки может ввести QA-специалиста в ступор: нет ни кнопок, ни полей, ни понятного формата обращения к сервисам. Облегчают взаимодействие с API специальные инструменты. Наиболее популярные среди них — SoapUI и Postman.
SoapUI. Приложение с открытым исходным кодом для тестирования Soap и Rest API. SoapUI был первоначально выпущен для SourceForge в сентябре 2005 года. Это бесплатное программное обеспечение с публичной лицензией Европейского Союза. Начиная с первого выпуска, SoapUI был загружен более 2 000 000 раз. Он полностью построен на платформе Java и использует Swing для пользовательского интерфейса (то есть SoapUI — кроссплатформенный). Его функциональные возможности включают проверку веб-службы, запуск, разработку, моделирование и макетирование, функциональное тестирование, тестирование нагрузки и соответствия.
Компания-разработчик программного обеспечения SmartBear также создала коммерческую версию SoapUI Pro (ныне носит название ReadyAPI), которая в основном фокусируется на функциях, предназначенных для повышения производительности. SoapUI может тестировать веб-сервисы SOAP и REST, JMS, AMF, а также выполнять любые вызовы HTTP(S) и JDBC. Для написания автоматизированных скриптов используется язык Groovy.
Postman. Как говорят его создатели, это своего рода швейцарский нож, который позволяет формировать и выполнять запросы, документировать и мониторить сервисы в одном месте. Тестировщики могут писать тесты и производить автоматизированное тестирование прямо из Postman.
Его основное предназначение — создавать коллекции с запросами к API. Коллекции позволяют удобно хранить запросы к тестируемому или разрабатываемому приложению, а новичку на проекте быстро разобраться с запросами к приложению. Кроме того, команда разработки может с легкостью использовать Postman для проектирования дизайна API. Для написания автоматизированных скриптов в Postman используется JavaScript.
Почему мы выбрали именно Cucumber и Spock?
В использовании SoapUI и Postman есть свои нюансы. Подобные тесты очень трудно поддерживать и проблематично использовать системы контроля версий (git, например) для их хранения.
Несмотря на то, что они широко используются в автоматизированном тестировании, SoapUI и Postman позволяют запускать тесты только локально и не могут применяться в системах интеграции (Jenkins). Для решения подобной задачи наша команда обратилась к Cucumber и Spock. С ними можно запускать тесты с Jenkins удаленно. Кроме того, эти фреймворки позволяют создавать автоматизированные смок-тесты, которые запускаются во время установки приложения. А вот с помощью Postman или SoapUI такое сделать не получится.
Spock и Cucumber отражают философию Behavior Driven Development — разработки через поведение. Идея BDD заключается в том, что перед тем, как написать какой-либо тест, необходимо сначала описать на предметно-ориентированном языке желаемый результат от добавляемой функциональности. После этого полученная документация передается разработчикам.
Спецификация поведения подается в полу формальном виде и имеет следующую структуру:
Заголовок (Title) — в сослагательной форме дается описание бизнес-цели.
Описание (Narrative) — в краткой форме даются ответы на следующие вопросы:
кто является заинтересованным лицом данной истории;
что входит в состав истории;
какую ценность эта история представляет для бизнеса.
Сценарии (Scenarios) — спецификация может содержать один и более сценариев, каждый из которых раскрывает одну из ситуаций поведения пользователя.
Сценарий обычно строится по одной и той же схеме:
одно или несколько начальных условий (Given);
событие, которое инициирует начало этого сценария (When);
ожидаемый результат или результаты (Then).
BDD не предоставляет каких-либо формальных правил, но настаивает на том, чтобы использовался ограниченный стандартный набор фраз, включающий все элементы спецификации поведения. В 2007 году «отец» BDD Дэн Норт предложил шаблон для спецификации, который обрел широкую популярность и впоследствии стал известен, как язык Gherkin.
На сегодня один из самых популярных инструментов BDD — Cucumber. Его авторы стремились объединить автоматизированные приемочные испытания, функциональные требования и документацию ПО в единый формат, понятный и техническим, и нетехническим участникам проекта.
Основой описания сценария тестирования являются шаги Given, When, Then. Каждому из них соответствует аннотация, которая с помощью регулярного выражения связывает метод со строкой в текстовом описании сценария. Шаги тестирования группируются в сценарии (Scenario), которые в свою очередь описывают определенную функциональность (Feature).
Для автоматизации описанных сценариев в Cucumber можно использовать Ruby, Java и Python. Тест записывается в виде Gherkin-нотации в отдельный файл с расширением *.feature. Этот файл может содержать один или несколько сценариев. Сценарии могут писать BA или мануальные QA. Далее специалист, занимающийся автоматизацией тестов, создает отдельный класс с реализацией шагов на определенном языке программирования.
С Cucumber фреймворком я познакомился во время написания сценариев поведения тестируемого API приложения. Точнее говоря, это был не сам Cucumber, а язык Gherkin и наши попытки описывать сценарии поведения приложения согласно правилам BDD. С точки зрения мануального тестировщика это интересный опыт. В команде было несколько мануальных тестировщиков, которые писали сценарии на Gherkin. Основная проблема состояла в сложности договориться с ними о едином формате описания каждого шага и создания набора шагов, которые могут повторяться в разных тестах, чтобы не дублировать их реализацию.
Feature: Test OpenWeather API
As a customer
In order to check weather
I want to get my city name in response.
Scenario Outline: Check if city name is returned correctly
When Sent request to openweathermap for “<cityReq>”
Then Check that 200 response code is returned
And Server returns correct city name “<cityResp>”
Examples
| cityReq | cityResp |
| “Kharkiv, UA” | “Kharkiv” |
| “London, GB” | “London” |На примере выше представлена Gherkin-нотация сценария для тестирования открытого OpenWeather API приложения. Для примера я написал простой сценарий, который отправляет запрос с определенными параметрами на сервер приложения и затем проверяет ответ с этого сервера.
public class Stepdefs {
@when ( “Sent request to openweathermap for {cityReq} “ )
public void sent_request_to_ openweathermap ( String cityReq) {
HTTP Builder http = null;
try {
http = new HTTP Builder (testUrl);
String [ ] actualCity = cityReq.split ( regex: “, “ ) ;Здесь в коде представлен пример класса Stepsdef на языке Java. Каждый шаг из feature файла привязывается к его реализации в Stepsdef классе с помощью аннотации (@Given, @When, @Then и тд.) и текста шага из feature файла.
Чтобы получить максимальную отдачу от Cucumber, нужно следовать принципам BDD, потому что Cucumber — только активатор для BDD.
Spock — это тестовая среда. Некоторые даже сказали бы «язык, построенный на базе языка Groovy». К этому фреймворку я обратился уже на другом проекте, где выступал в роли автоматизатора. Как я писал ранее, в Cucumber сценарии выполнения и реализация каждой конструкции разделены. Это позволяет составить удобочитаемые сценарии, но занимает много времени. Поэтому такой подход может быть непрактичным при написании реализации.
Описание шагов и их реализация в Spock находятся в одном groovy классе. Благодаря использованию в качестве основы платформы JUnit, этот фреймворк совместим со всеми популярными IDE (в частности, IntelliJ IDEA), различными инструментами сборки (Ant, Gradle, Maven) и CI-сервисами (continuous integration). Тестовый класс являет собой набор методов-сценариев с названиями в кавычках, подобные названиям сценариев в Cucumber. А поскольку эти классы являются производными от JUnit, есть возможность запускать их из IDE как обычный модульный тест Groovy. При этом мы получаем стандартные JUnit отчеты, что очень удобно при разработке и отладке автоматизированных тестов.
В Spock каждая фаза теста выделена в отдельный блок кода, который начинается с лейбла и завершается началом следующего блока кода или окончанием теста. Блок Given отвечает за настройку начальных условий теста. В блоке When — стимулятор, раздражитель системы, а в блоке Then — ответная реакция системы. Оба блока всегда используются вместе. Если есть возможность сократить конструкцию When-Then до одного выражения, можно использовать один блок Expect.
class WeatherTestSpec extends Specification {
@Shared def testUrl, testResponse
def setupSpec () {
testUrl = “http:// api. openweathermap.org”
testRequest = [ ‘APPID’ : “aaa” ]
testResponse = ‘ ‘
}
def ‘ Check if city name and coordinates is returned correctly’ () {
when: ‘ Sent request to openweathermap’
def http = new HTTPBuilder(testUrl)
testRequest.put ( ‘q’, cityReq)
testResponse = http.get( path : ‘/data/2.5/weather’ , query : testRequest )
then: “Check that 200 response code is returned”
testResponse. cod == 200
and: “Server returns correct city name”
testResponse. name == cityResp
where:
cityReq << [ “Kharkiv, UA”” , “London, GB”” ]
cityResp << [ “Kharkiv”” , “London ” ]
}
На примере выше представлен Groovy класс с тестом на Spock. Описание шага идет после символа «:» и представляет произвольную строку. При этом оно не является обязательным элементом. Spock допускает создание спецификации теста без описания шагов. Однако такая практика не считается общепринятой и в будущем приводит к затруднению понимания логики теста.
А что лучше?
И Cucumber, и Spock тесно связывают спецификацию на человеческом языке с тестовым кодом. Это прямое следствие парадигмы BDD, для поддержки которой создали обе платформы. Но Cucumber делает это более строго. Большие изменения описания шага на человеческом языке нарушат тестовый код, например, с отсутствующей реализацией шага, если ни одно регулярное выражение метода не соответствует заданному тексту шага. В то время как для Spock текст представляет собой произвольную строку после символа «:». Описание шага проверяется на соответствие в последующей реализации.
Cucumber четко разделяет спецификацию на человеческом языке и тестовым кодом. Для нетехнических специалистов, которые пишут или читают спецификации, это безусловно удобно. Да и сама суть BDD — это тесное сотрудничество Product Owner, BA, QA, архитекторов и разработчиков. Так что в случае с Cucumber спецификация будет согласована и понятна всем участникам проекта до начала разработки.
С другой стороны, Spock предлагает быстрое, краткое и однофайловое решение. Возможность Groovy использовать любую строку в качестве названия метода позволяет применять удобные для восприятия названия отдельного тестового сценария. Spock дает разработчикам единую точку для чтения и понимания спецификации и кода, который ее реализует. А еще давайте не забывать о «плюшках», с которыми поставляется Spock (например, расширенные возможности таблицы данных).
Также стоит отметить, что Cucumber подходит исключительно для интеграционных тестов. В то время, как Spock может использоваться и для Unit-тестов.
Было бы неправильно определять, какой из этих способов автоматизации тестирования API однозначно лучше. Мы в NIX, в зависимости от задач и целей, выбираем и то, и другое. SoapUI и Postman отлично подходят на начальных этапах автоматизации, когда в команде нет или очень мало автоматизаторов. С ростом команды логичнее переходить на Cucumber или Spock. У каждого из этих фреймворков есть свои преимущества, которые упрощают рутинные задачи QA-специалистов и делают процесс тестирования более эффективным.
