serenity bdd что это

Тестирование RESTful API при помощи Serenity и REST Assured на Kotlin

В этой заметке попробуем разобраться с тем, как на языке Kotlin написать тесты для проверки RESTful API приложения. В интернете полно статей про то, как писать подобные тесты на Java и Serenity, мы же воспользуемся Kotlin.

Какие технологии и библиотеки будем использовать:

Что такое Serenity BDD?

Краткий список возможностей:

Что такое Rest Assured?

Rest Assured — это Java-библиотека для тестирования RESTful API. Код, написанный с помощью этой библиотеки, имеет простой и понятный синтаксис. В тесте можно выполнить запрос к API буквально в одну строчку кода и при помощи DSL синтаксиса проверять полученный результат.

Подготовка

В оригинальной статье в качестве сборщика проекта используется maven, мы же воспользуемся Gradle. (https://gradle.org/maven-vs-gradle/)

Перед тем как приступить к написанию тестов, необходимо:

Настройка проекта в IDE

Создаем новый проект (Create new project), выбираем Gradle — Kotlin (Java):

Заполняем необходимые поля:

Указываем путь к gradle. У меня в MacOS он установлен через homebrew и Idea не находит его автоматически, поэтому я указываю путь руками: /usr/local/Cellar/gradle/4.2.1/libexec:

В итоге получаем пустой проект, с настроенным файлом конфигурации build.gradle, в котором все, что необходимо для написания кода на Kotlin, уже подключено.

Настройка зависимостей

Нам необходимо подключить следующие библиотеки:

Вносим изменения в build.gradle. Жирным шрифтом отмечены сделанные изменения относительно той версии, которая получилась после создания проекта.

Вот и вся настройка. Перейдем к написанию тестов.

Первый тест

Для написания тестов нам необходим какой-либо веб-сайт, работающий по RESTful API. Воспользуемся http://www.groupkt.com/, который предоставляет сервисы, с помощью которых, например, можно выполнить поиск страны по коду ISO при помощи метода API /country/get/iso2code/

Ниже приведён ответ сервера в формате JSON:

В папке serenity-rest-assured-automation/src/test/kotlin/tests/ создаем файл GroupktAPITest.kt и добавляем в него следующий текст:

Тест делает запрос на адрес http://services.groupkt.com/country/get/iso2code/RU и проверяет, что в ответе в поле RestResponse.result.name содержится значение “ Russian Federation”

Кстати, код взят из оригинальной статьи и автоматически конвертирован из Java в Kotlin при его вставке в Idea. При этом некоторые инструкции (when, is) были экранированы при помощи символа «, так как они являются ключевыми словами в Kotlin.

Попробуем запустить тест.

Запуск тестов

Тесты можно запускать двумя способами: через JUnit и через Gradle.

Чтобы запустить тесты через JUnit, в Idea надо навести мышь на значок запуска слева от строки, в которой объявлен класс и выбрать Run Test:

После прогона тестов (в нашем случае одного теста), внизу окна Idea отобразится результат тестирования:

Теперь настроим запуск тестов через Gradle и в дальнейшем будем пользоваться этим способом запуска.

3. Выбираем Gradle project из выпадающего списка

Сохраняем изменения и запускаем тест при помощи Gradle. После прогона увидим результат:

Посмотрим, как выглядит упавший тест. Для этого поменяем в тесте код страны и запустим тест заново:

В логе можно увидеть причину падения:

Возвращаем код страны обратно на RU.

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

Добавляем еще тесты

Добавим поиск США и Индии по их ISO-кодам:

Полную версию можно посмотреть тут.

Если посмотреть на код, то можно увидеть, что в нём повторяются одни и те же инструкции для каждого теста:

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

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

Рассмотрим второй вариант.

В Serenity тесты принято разбивать на небольшие блоки кода, которые затем можно использовать повторно при необходимости. Эти блоки называются “шагами”. Применяя подобный принцип на практике, можно перейти от использования технических формулировок (“код http-ответа = 200” или “выполни http запрос”) к выражениям, понятным обычному человеку: “действие было успешным” или “выполни поиск”. Поэтому всегда лучше начинать с реализации маленьких шагов, описывающих какие-либо действия, а затем использовать их для создания более сложных шагов и сценариев. В общем, чтобы сделать тесты легко поддерживаемыми необходимо использовать принцип DRY (Don’t Repeat Yourself)

Выносим шаги в отдельный пакет

Создаем новый файл src/test/kotlin/steps/CountriesSearchSteps.kt :

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

Класс и его методы объявлены как open. Это необходимо, чтобы Serenity мог корректно сформировать отчёт, детализируя его пошагово.

Запускаем прогон тестов. Он должен завершиться успешно.

Теперь мы можем спокойно добавить дополнительный шаг и применить его в одном тесте.

Параметризованные тесты

Библиотека Serenity имеет встроенные механизмы для создания параметризованных тестов. Тестовые данные можно подгружать из csv-файла или задать в коде. Рассмотрим второй вариант.

Что необходимо сделать:

В итоге Serenity при инициализации тестового класса будет передавать в него очередную порцию тестовых данных и запускать все тесты внутри класса. К тестовым данным можно получить доступ через атрибуты класса.

Отчёты

Чтобы формировался отчет, необходимо использовать команду aggregate, которую мы добавили ранее при настройке запуска тестов через Gradle.

Сформированный отчет можно найти в каталоге target/site/serenity/. Переходим в этот каталог и открываем файл index.html:

В отчете можно увидеть шаги, которые выполнялись в каждом тесте и даже результаты http- запросов.

Источник

An Introduction to BDD Test Automation with Serenity and JUnit

Serenity BDD (previously known as Thucydides) is an open source reporting library that helps you write better structured, more maintainable automated acceptance criteria, and also produces rich meaningful test reports (or «living documentation») that not only report on the test results, but also what features have been tested. And for when your automated acceptance tests exercise a web interface, Serenity comes with a host of features that make writing your automated web tests easier and faster.

1. BDD fundamentals

But before we get into the nitty-gritty details, let’s talk about Behaviour Driven Development, which is a core concept underlying many of Serenity’s features. Behaviour Driven Development, or BDD, is an approach where teams use conversations around concrete examples to build up a shared understanding of the features they are supposed to build.

For example, suppose you are building a site where artists and craftspeople can sell their good online. One important feature for such a site would be the search feature. You might express this feature using a story-card format commonly used in agile projects like this:

To build up a shared understanding of this requirement, you could talk through a few concrete examples. The converstaion might go something like this:

«So give me an example of how a search might work.»

«Well, if I search for wool, then I should see only woolen products.»

«Sound’s simple enough. Are there any other variations on the search feature that would produce different outcomes?»

«Well, I could also filter the search results; for example, I could look for only handmade woolen products.»

And so on. In practice, many of the examples that get discussed become «acceptance criteria» for the features. And many of these acceptance criteria become automated acceptance tests. Automating acceptence tests provides valuable feedback to the whole team, as these tests, unlike unit and integrationt tests, are typically expressed in business terms, and can be easily understood by non-developers. And, as we will se later on in this article, the reports that are produced when these teste are executed give a clear picture of the state of the application.

2. Serenity BDD and JUnit

In this article, we will learn how to use Serenity BDD using nothing more than JUnit, Serenity BDD, and a little Selenium WebDriver. Automated acceptance tests can use more specialized BDD tools such as Cucumber or JBehave, but many teams like to keep it simple, and use more conventional unit testing tools like JUnit. This is fine: the essence of the BDD approach lies in the conversations that the teams have to discuss the requirements and discover the acceptance criteria.

2.1. Writing the acceptance test

Let’s start off with a simple example. The first example that was discussed was searching for wool. The corresponding automated acceptance test for this example in JUnit looks like this:

There are several things to point out here. When you use Serenity with JUnit, you need to use the SerenityRunner test runner. This instruments the JUnit class and instantiates the WebDriver driver (if it is a web test), as well as any step libraries and page objects that you use in your test (more on these later).

The @Managed annotation tells Serenity that this is a web test. Serenity takes care of instantiating the WebDriver instance, opening the browser, and shutting it down at the end of the test. You can also use this annotation to specify what browser you want to use, or if you want to keep the browser open during all of the tests in this test case.

The @Steps annotation tells Serenity that this variable is a Step Library. In Serenity, we use Step Libraries to add a layer of abstraction between the «what» and the «how» of our acceptance tests. At the top level, the step methods document «what» the acceptance test is doing, in fairly implementation-neutral, business-friendly terms. So we say «searches for items containing wool«, not «enters wool into the search field and clicks on the search button». This layered approach makes the tests both easier to understand and to maintain, and helps build up a great library of reusable business-level steps that we can use in other tests.

2.2. The Step Library

The Step Library class is just an ordinary Java class, with methods annotated with the @Step annotation:

For automated web tests, the step library methods do not call WebDriver directly, but rather they typically interact with Page Objects.

2.3. The Page Objects

Page Objects encapsulate how a test interacts with a particular web page. They hide the WebDriver implementation details about how elements on a page are accessed and manipulated behind more business-friendly methods. Like steps, Page Objects are reusable components that make the tests easier to understand and to maintain.

Serenity automatically instantiates Page Objects for you, and injects the current WebDriver instance. All you need to worry about is the WebDriver code that interacts with the page. And Serenity provides a few shortcuts to make this easier as well. For example, here is the page object for the Home page:

And here is the second page object we use:

In both cases, we are hiding the WebDriver implementation of how we access the page elements inside the page object methods. This makes the code both easier to read and reduces the places you need to change if a page is modified.

This approach encourages a very high degree of reuse. For example, the second example mentioned at the start of this article involved filtering results by type. The corresponding automated acceptance criteria might look like this:

Notice how most of the methods here are reused from the previous steps: in fact, only two new methods are required.

3. Reporting and Living Documentation

Reporting is one of Serenity’s fortes. Serenity not only reports on whether a test passes or fails, but documents what it did, in a step-by-step narrative format that inculdes test data and screenshots for web tests. For example, the following page illustrates the test results for our first acceptance criteria:

But test outcomes are only part of the picture. It is also important to know what work has been done, and what is work in progress. Serenity provides the @Pending annotation, that lets you indicate that a scenario is not yet completed, but has been scheduled for work, as illustrated here:

This test will appear in the reports as Pending (blue in the graphs):

We can also organize our acceptance tests in terms of the features or requirements they are testing. One simple approach is to organize your requirements in suitably-named packages:

With this configured, Serenity will report about how well each requirement has been tested, and will also tell you about the requirements that have not been tested:

4. Conclusion

Hopefully this will be enough to get you started with Serenity.

That said, we have barely scratched the surface of what Serenity can do for your automated acceptance tests. You can read more about Serenity, and the principles behind it, by reading the Users Manual, or by reading BDD in Action, which devotes several chapters to these practices. And be sure to check out the online courses at Parleys.

You can get the source code for the project discussed in this article on GitHub.

Источник

Введение в автоматизацию тестирования BDD с помощью Serenity и Cucumber-JVM

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

1. Основы BDD

Поведенческая разработка, которая является основной концепцией, лежащей в основе многих функций Serenity. Команда, использующая Behavior Driven Development, использует беседы и совместную работу на конкретных примерах для выработки общего понимания функций, которые они должны создавать. Беседы о конкретных примерах и контрпримеры — отличный способ избавиться от любых скрытых предположений или недопонимания относительно того, что должна делать функция.

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

Чтобы сформировать общее понимание этого требования, вы можете обсудить несколько конкретных примеров. Разговор может идти примерно так:

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

2. Написание критериев приемки с помощью Cucumber-JVM

Cucumber — популярный инструмент автоматизации тестирования BDD. Cucumber-JVM — это Java-реализация Cucumber, на которой мы сосредоточимся в этой статье. В Cucumber вы выражаете критерии принятия в естественной, удобочитаемой форме. Например, мы могли бы написать пример «шерстяной шарф», упомянутый выше:

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

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

3. Написание исполняемых спецификаций с Cucumber и Serenity

3.1. Написание сценария

Давайте начнем с первого примера, описанного выше. В Cucumber сценарии хранятся в файлах объектов, которые содержат общее описание функции, а также ряд сценариев. Файл функций для приведенного выше примера вызывается search_by_keyword.feature и выглядит примерно так:

Эти файлы функций могут быть размещены в разных местах, но вы можете уменьшить объем конфигурации, который вам нужно сделать с Serenity, если вы поместите их в src/test/resources/features каталог.

Вы обычно организуете файлы объектов в подкаталогах, которые отражают требования более высокого уровня. Например, в следующей структуре каталогов у нас есть определения функций для нескольких функций более высокого уровня: search и shopping_cart :

3.2. Сценарий Бегун

3.3. Определения шагов

Файлы определений шагов должны находиться внутри или под пакетом, содержащим бегуны сценария:

3.4. Библиотеки «Шаг безмятежности»

Библиотека шагов Serenity — это обычный Java-класс с методами, помеченными @Step аннотацией, как показано здесь:

3.5. Объекты страницы

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

Serenity автоматически создает экземпляры Page Objects для вас и внедряет текущий экземпляр WebDriver. Все, что вам нужно беспокоиться, это код WebDriver, который взаимодействует со страницей. И Serenity предлагает несколько быстрых клавиш, чтобы сделать это проще. Например, вот объект страницы для домашней страницы:

И вот второй объект страницы, который мы используем:

В обоих случаях мы скрываем реализацию WebDriver от способа доступа к элементам страницы внутри методов объекта страницы. Это делает код более легким для чтения и уменьшает количество мест, которые необходимо изменить, если страница изменена.

4. Отчетная и живая документация

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

Обратите внимание, как этот отчет точно воспроизводит пример из беседы с бизнесом, а также дает возможность перейти к «что», чтобы увидеть, как был выполнен определенный шаг, и (в данном случае), как выглядят соответствующие снимки экрана. как.

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

Но результаты тестов являются лишь частью картины. Также важно знать, какая работа была проделана и какая работа в процессе. При использовании Cucumber любой сценарий, содержащий шаги без соответствующих методов определения шагов, будет отображаться в отчетах как Ожидание (синий на графиках):

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

5. Вывод

Надеюсь, этого будет достаточно, чтобы вы почувствовали вкус Serenity и Cucumber-JVM.

Источник

Testing Web Applications with Serenity

Serenity BDD provides excellent integration with Selenium, which allows you to avoid a lot of the boilerplate and infrastructure code you normally need to deal with in automated web tests. In particular, Serenity manages the driver lifecycle for you (so you don’t need to create your own driver instances, or close them at the end of the tests). Serenity can also be configured to automatically take screenshots throughout the tests, creating rich documentation of how each test played out. When you write your tests in a fluent, readable manner, these screenshots become part of the «living documentation» of your application.

Selenium versions

A simple Selenium web test

Serenity reduces the amount of code you need to write and maintain when you write web tests. For example, it takes care of creating WebDriver instances, and of opening and closing the browser for you. The following is a very simple Selenium web test using Serenity:

This test would not scale well for a real application. In the following chapters, we will see how to use patterns such as Page Objects and Screenplay to make your web tests easier to maintain as they grow in number. But in this chapter, we will just focus on configuring your WebDriver setup.

Configuring the driver

The webdriver.driver property

Using the serenity.properties file

You can add the webdriver.driver property to your serenity.properties file in the root of your project, e.g.

You can also create a serenity.conf file, which uses the Typesafe Config notation, and add this to your classpath (for example in src/test/resources ).

Using the command line

Using the @Managed annotation

If you always need a test to be run with a particular browser, and you are using JUnit, you can use the browser option in the @Managed annotation, e.g.

The Managed annotation take priority over driver values passed in on the command line.

Using the @driver tag

In JBehave, you can use the Meta tag instead:

Источник