If you don’t have a dog ...

If your business needs BDD with live documentation in Russian, there is no tester’s dedicated position, or his level of knowledge is insufficient for independent automation and it is important to provide a single technology stack between scrum teams, then you certainly need to connect our Akita library at least once and check it in action.
Before embarking on stories about what the Akita library is, I would like to tell how we got to the idea of ​​its implementation, what problems we wanted to solve, and what we ended up with.

The article was prepared by Anna anna-che , Alice mutaliska and Ksenia KseMish .

What did you want?

Like many companies that want to continuously deliver high-quality software to the user, we wanted to implement Continuous Delivery, which could allow us to deliver ready-made functionality fully covered by tests and relevant documentation within one sprint. But during the transition to CD, we came across a number of features of our development process.

What happened?

1. A large number of scrum commands.
2. High resource costs.
3. Long regression.

After analyzing these features, we did not give up, but found for ourselves two options for action that would allow us to enter the Continuous Delivery path:

1. Attract one autotest developer to each team.
2. Train your team testers (and not only them) to write autotests.

The first option did not suit us because there are not many free developers of autotests on the market, and it’s expensive. But the second interested us in its cost-effectiveness and scalability.

What should be done?

• To develop a single tool for test automation, which will allow:
• Set a low threshold for the tester to enter the command.
• Have minimal knowledge of the programming language to start automation.
• Write autotests not only to the tester, but also to any member of the team (not only the tester is responsible for the quality of the product!).
• Reduce the time to develop autotests.
• Use a single technology stack in all teams.

What happened?

Akita was born. Akita library, named after the breed of the notorious dog from the movie “Hachiko”. We associate this name with a true friend who is always ready to come to the rescue and protect our systems from a large number of defects.

At the moment, Akita consists of more than 60 implemented steps, using which you can already assume that you are automating the testing of your web application.

How does it work?

Akita is a BDD step library for test automation. BDD is a development methodology based on a description of user behavior. That is, there is a person (or people) who writes descriptions of the form "as a user I want to see a schedule of monthly expenses when I click on the 'per month' button to plan my future expenses." Such a description serves as an entry point into development. To describe the steps of a script in BDD frameworks, the keywords given, when, then are used (given when, then, respectively).

In the library, tests are written in Russian and represent user scripts that can act as user documentation for the application. Each user script consists of steps, which, in turn, are tied to specific java methods, where the implementation is implemented.


The project template using the library is built quite simply and looks like this:


The main components of the template using Akita are feature files, steps (hereinafter referred to as steps) and web pages (hereinafter referred to as pages). The feature files describe a list of scripts (tests) that we cover our system with, and they will be launched in the future. Steps stores the developed methods that are associated with the steps described in the feature files. The description of web pages with their elements is in the pages package.

In order to understand the principle of working with the library, we suggest considering the following example.

Any member of the scrum team (in our case, an analyst or tester) makes up a user script (user story), which, in the future, can act as a development task, as a set of checks for autotests, as well as user documentation.
For example, we have a user story: “An Alfa-Bank user logs in to the Alfa-Click system with a username / password to see his accounts.”

The tester (or another team member) needs to:

1. Create a java gradle project and add the following entities depending on:

• Akita:
  en.alfabank.tests: akita: 3.1.0
• Plugin for generating and attaching reports:
  en.alfalab.gradle: cucumber-reporting-gradle-plugin: 0.1.0
• Plugin for running tests in parallel:
  en.alfalab.gradle: cucumber-parallel-test-gradle-plugin: 0.2.1
• A bunch with the implementation of steps:
  generateRunner.glue = ["en.alfabank.steps", "steps"]

2. Transfer the completed user scripts to the project .feature file using ready-made steps from the Akita library. After that, our feature-file will look like this:

Функционал: Логин в Альфа-клик
 Сценарий: Успешный логин в Альфа-клик скролл внутри
 Дано совершен переход на страницу "Страница входа" по ссылке "http://alfabank.ru"
 Когда в поле "Логин" введено значение "login"
 Когда в поле "Пароль" введено значение "password"
 И выполнено нажатие на кнопку "Войти"
 Тогда страница "Альфа-клик" загрузилась

3 . Create Page Object for pages with elements of which you need to work: login page and main page “Alpha-click”. Create a class for the Login page (LoginPage) in the pages package:

@Name("Страница входа")
public class LoginPage extends AkitaPage {
       @FindBy(id = "login")
       @Name("Логин")
       private SelenideElement login;
       @FindBy(id = "password")
       @Name("Пароль")
       private SelenideElement password;
       @FindBy(id = "submit")
       @Name("Войти")
       private SelenideElement submitButton;
}

Here it is important to inherit from AkitaPage and hang annotation @Nameover the class and page elements with their key description, which we use in the .feature file. Similarly, you need to describe all the pages that will participate in the checks.

After we have described all the pages, the question arises: “But how do you understand that the page has loaded?”. In the step “Then the Alpha Click page has loaded”, the Alpha Click page is set as current and all SelenideElements are searched. If all the elements are found, then the page has loaded.

The implementation of this step in the library looks like this:

/**
* Проверка того, что все элементы, которые описаны в классе страницы с аннотацией @Name, но без аннотации @Optional появились на странице
* в течение WAITING_APPEAR_TIMEOUT, которое равно значению свойства "waitingAppearTimeout" из application.properties. Если свойство не найдено, время таймаута равно 8 секундам
*/
@Тогда("^(?:страница|блок|форма|вкладка) \"([^\"]*)\" (?:загрузилась|загрузился)$")
public void loadPage(String nameOfPage) {
   akitaScenario.setCurrentPage(akitaScenario.getPage(nameOfPage));
   akitaScenario.getCurrentPage().appeared();
}

If the element belongs to the page, but may not be displayed immediately upon loading (for example, a message about incorrectly entered data), then it should not participate in the decision to load and is marked with the @Optional annotation, i.e. it is not required.

4. Run the test.

There are several ways to run tests:

• gradle task: test, generateCucumberReport
• context menu for a specific feature-file, where you should not forget about installing VM Properties: -Dbrowser = chrome
• from terminal:

> gradlew clean test -i
> gradlew clean test -Pbrowse=chrome -Pprofile=local -PremoteHub=http://remote/wd/hub
> gradlew clean test -Dbrowser=chrome -Ptag=@test

For projects, parallel launch of all feature files is provided (each run-file has its own runner), tests run on a remote machine (-PremoteHub), browser change (-Pbrowser = chrome), tests run according to tags set in scripts (-Ptag) .

To receive a report after running the tests, you need to run the following commands in the terminal: As a result, a standard Cucumber report (build / reports) is generated :

> gradlew generateCucumberReport
> gradlew gCR




And that’s all. Our user story is covered in tests, user documentation has been generated, and a report on passing the tests has been generated.

In order to try to work with Akita, you can download the ready-made template project on github (Akita-testing-template) .

After analyzing the main problems that testing automation faced, we included the following features in Akita:

1. Work with REST requests

In the library, you can send REST requests and save the responses in a variable. Akita supports the following request types:

GET | POST | PUT | DELETE

And in the variable table you can use the types: header, parameter, body.

For the body parameter, both work with the request body stored in the requestBodies folder is organized , as well as with the text body in the step in the corresponding cell. Values ​​for table parameters and url parts can be specified in application.properties . Example step with REST:

2. Use of variables

Sometimes there is a need to use values ​​from one step in subsequent ones. For this, a variable storage is implemented in AkitaScenario. To save / retrieve variables, setVar / getVar methods are used.

Saving a variable in the repository:

akitaScenario.setVar(<имя переменной>, <значение переменной>);

Retrieving the value of a variable from the repository:

akitaScenario.getVar(<имя переменной>)

3. Storage of test data

To specify additional parameters or test data, you need to create the application.properties file in main / java / resources in your project .

What did you do?

Having studied all the technologies used and their analogues, we came to the following stack: Java + Gradle + Selenide + Cucumber.

We use Java and Gradle in Alfa-Bank, so there wasn’t much sharp choice here.

Cucumber replaced JBehave, because Cucumber is easier to work with and has a fairly large community, which greatly facilitates its use.

The Selenide library makes it easier to work with the browser, timeouts, dynamic pages and Ajax requests. Selenide author Andrei Solntsev noted our library in his LJ and gave some valuable tips when reviewing the original code.

What are the benefits?

Using the Akita library brought the following results:

1. The entry threshold for a new employee has decreased (currently primary onboarding takes 1-2 days, free orientation in the tool is achieved in 2 weeks, because to use the basic capabilities of the library knowledge of the programming language should be minimal).
2. A single tool has been installed to automate testing web applications (currently, more than 20 teams in Alfa Bank use the library).
3. Acceptance + regression takes no more than an hour (due to the fact that most of the functionality - about 80% is covered by autotests, regression is much faster).

Akita from day to day, from sprint to sprint helps us to deliver users an increasingly high-quality product. So it is safe to say that if you have our library, then automated testing will be much more interesting and easier.

Already say

Akita was the subject of discussion at the Heisenbug (December 8-9, 2017, Moscow) and Delex (February 17, 2018, Minsk) conferences . Already on March 2 and 3, the Selenium Camp will be held in Kiev , where we will once again tell and demonstrate how to work with Akita.

We consider our great victory that thanks to the Akita library, the guys from our alfalab team won first place at the international Hackathon for test automation (October 20, 2017, Vilnius), being able to demonstrate how much faster and easier to implement testing automation.

If you don’t have a dog ... you can download it on github: Akita library , as well as download the akita-testing-templatefor a quick start.

In addition, Akita has its own community in Telegram . Join us!

If you want to become one of Alfa-Bank 's testers (or not just a tester), we have open vacancies .