Experience using BDD

About seven years ago, Dan North in his article described the practical application of the BDD approach, which allows you to make the development process more understandable and manageable by establishing internal communications. The industry every day shows a growing interest in this methodology, aimed at the productive interaction of standard teams like "analytics-development-testing".

However, now only a small number of companies decide to use BDD. Why?

So let's see. BDD (Behavior Driven Development - “Development through Behavior”) is a flexible methodology, closely related to TDD (Test Driven Development - “Development through Testing”). By experience, even experienced testers often do not see the difference between these methodologies. Indeed, at first glance it is difficult to isolate it: both approaches involve writing documentation and tests before the start of the development phase. And the difference is this: in BDD, to describe tests, it is necessary to use a natural language that is understood by each project participant in order to, in fact, combine the formulation of the problem, tests and documentation together. In other words, DSL (a specific domain-specific language) is determined, then a standard limited set of phrases describing the behavior of the necessary elements is compiled. Then, with their help, a scenario of using new functionality is developed, which will be clear to everyone.

Let's see the difference once and it will become obvious:

We will touch upon this example, and first, let's look at the whole variety of methodologies that currently have non-zero relevance.

Compare a few methodologies

The diagram below shows a comparison of the three approaches: TDD, TLD (Test Last Development) and BDD:

• When we work on the BDD methodology, auto-testing and specification writing accompanies each stage of the software development cycle, which ensures the continued relevance of auto-tests and documentation.
• TDD and ATDD (Acceptance Testing) methodologies are combined in one block in the diagram, because written at the stage of analytics. As mentioned above, TDD is based on writing tests before developing a functional. The developer must write tests in order to write a functional for the test.
• TLD (Test Last Development) includes testing after the implementation of the functional.
• BDD is universal and can be included at any stage of development.

The second diagram shows the involvement of participants in the development process in writing scripts.

• In BDD, any team member, for example, analyst, business user, developer and tester, can connect to tests at any stage, since the tests are clear to all participants in the process.
• BDD is still useful because you don’t need to spend a lot of time writing all sorts of documentation. With the classical design scheme, at a minimum, specifications and test scenarios are usually needed, which are usually written by different people. In BDD, the specification is a test case, and at the same time it is an autotest. Testers do not need to write separate test documentation - an analyst has already done this for them, having written the specification from natural language constructs (which can be read and understood by any team member).

Undoubtedly, BDD is a good tool for achieving product quality. Tests and documentation are written faster. For business, the project becomes more transparent, thanks to natural language constructs that can be understood by anyone far from programming.

This is about the pros. Nevertheless, as has already been said, despite the large number of advantages, very few people implement this methodology.

BDD is good for everyone, but why not use it?

The answer is simple: it is long and expensive. Most IT companies would agree with this statement. And at first we were no exception. BDD is inconvenient at least in that it requires the involvement of testing specialists at the stage of elaboration of requirements.

BDD reverses the classic pattern of development (TLD). It is poorly implementable because it is difficult. The development cycle is extended.

BDD is undoubtedly a way to achieve quality. But not everyone is willing to pay time and experts for this quality.

However, what to do if you still want to implement BDD?

You can try using ready-made frameworks. For example, Cucumber, Squish, Yulup.

The main problem of the complexity of BDD is not in the process, but in the implementation and existing tools. Take for example the WEB development of a corporate information system. Having a web implementation, we are faced with WebDriver, which is currently the standard for automating applications running in a web browser. He has quite a lot of features. To take into account the various customizations of the page elements, it is necessary to invent options for accessing them. And here, to facilitate the development of the test, various libraries come to the rescue (Selenide, etc.), which creates its own ecosystem, which you need to know. To work with WebDriver, you need a programmer or an automated tester, because everything is implemented using code and clever constructs.

Getting started with the BDD framework is difficult and time consuming.

Our attention was focused on the instrument called Gauge. This is a flexible and lightweight framework distributed under a free license. To be honest, we didn’t really study alternatives, because The use of Gauge was strongly dictated by our customer.

In Gauge, tests are written in specification files (files with the .spec extension). The specification contains test steps written in natural language. These steps are implemented in any programming language (we used the Java programming language). When implementing the steps, it is important that the Naming Convention is respected in both the script and implementation file names, and in the names of the implementation methods and script steps, they must completely coincide. Additional flexibility to this tool is given by the fact that steps may have parameters.

Gauge allowed us to use the benefits of BDD. However, we still faced problems that are difficult to implement: problems of tools and process implementation.

It turned out that engaging testers at an early stage has a bad effect on the final result. Increases time to develop tests. When using any framework, great efforts are required by the tester, who undoubtedly must be proficient in programming. Initially, the process of working with the script was as follows: the analyst told the test to the tester, and wrote it to the technical writer. While the tester understood the software implementation, the meaning of the tested functionality was changed. Here, the separation of the entry point affects, but it must be one, and as a result, the process is divided and turns into a “normal” process, from which I wanted to leave. Those. the entry point was divided, communications sprawled out, the tester went headlong into the implementation of the test, the technical writer understood somehow in his own way, and the analyst already rewrote his docks and changed his mind, the developer went into his own world).

A lot of time at the tester took the code. But still the same tester should have thought through the search for elements on the page. The situation resembled a well-known children's game: “A spoiled telephone”. There was a collapse. And we decided: BDD will work only if tests can write analytics. It is necessary to reduce the complexity of writing tests, simplify them. But for this you need to significantly simplify the testing interfaces. Testing tools, process implementation in conjunction with all approaches and libraries should be easier.

The work of the tester initially looked as follows:

1. Examine documentation, if any;
2. Drawing up the checklist;
3. Ad-hoc testing;
4. Making a test plan;
5. Refining the picture of the world from the analyst;
6. Refine the picture of the world from the developer;
7. If everything has grown together, writing test documentation, in parallel with testing;
8. Waiting for fix bugs, testing bugs;
9. Description of pages, controls, search for items on the page using the Web-Driver. The search for what is already implemented in the test system;
10. Writing test logic;
11. Release;
12. Support bug / Regress bug;
13. Specification update;
14. Fix bug;
15. AutoTest Update, updating a large number of changed controls;
16. Release;
17. ...
    Items in italics (1, 5, 6, 7, 9, 13, 15) lead to time costs. They can and should be optimized.

This list is briefly illustrated in the design process diagram:

Our company specializes in projects with web implementation of interfaces. Based on this, we use the Web Driver tool to interact with the web browser.

De facto, Selenium Web Driver is a standard, and it is used to describe web objects on any frameworks, including Gauge, jUnit, Masquerade libraries, and others. He has a lot of flexibility for different tasks, which creates unnecessary complexity in local-type tasks. We need to find a solution to reduce the complexity.

For example, we will show on the diagram - how Selenium Web Driver is connected, Gauge framework, Masquerade library, Java programming language.

In this scheme, instead of the BDD framework, you can put jUnit, TestNG or any other, any bundle will work, depending on your needs. Selenium and Masquerade will remain, the programming language can be changed.

Accelerating the process of writing code - connect Masquerade

In our company, development is carried out on the platform CUBA . And specifically for this platform, a tool was developed for autotests: Masquerade is a library that provides a concise and convenient API for working with code when implementing tests using WebDriver. This library is working on Selenium Web Driver, is friends with selenide and any frameworks.

In CUBA projects, each element of the web page contains cuba-id, which does not change. CUBA uses a component approach, and the Masquerade library simplifies interaction with web page elements. The library is able to perform actions with elements of a web page implemented using CUBA in a simpler way. Therefore, when searching for elements on the page, it is not necessary to use bulky constructions with XPath, as it was before:

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click(); 

Or more concise constructions in Java, which, nevertheless, are still cumbersome:

 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); } 

After connecting the Masquerade library, the description of the embedded control looks simple and easy to access. You can not even look for controls on the page, because in the project he is already there. Here is an example of the button description for the authorization form in the application:

In the page code, we see a clearly recognizable element cuba-id=”loginButton”

We describe the button using the Masquerade library:

 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton; 

A simple implementation of the test on the jUnit framework is an authorization block that is performed before each test:

 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); } 

And in the body of the login method, the following code:

 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click(); 

The most important thing is how we describe the page, how we address the elements. LoginWindow page description:

 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; } 

The search for items is only part of the capabilities of the Masquerade library. Appealing to elements of a web page allows you to perform various actions with these elements. For example, you can select an item from the drop-down list:

 getMaxResultsLayout().openOptionsPopup().select("5000") 

Or sort the table:

 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING); 

For a list of some actions with the table, see the screenshots below:

Using Masquerade greatly simplified writing tests, now, in order to write a test for new functionality, you need:

1. Using Masquerade to describe a page is easy and does not require special programming skills.
2. Collect in one class all the pages that are used when checking the functionality.
3. From ready-made natural language constructs, assemble a test script (substituting the names of the necessary elements there), that is, write a Gauge-specification.

Integrating Masquerade and Gauge

Before using BDD, the TLD approach was used and we also optimized the process of writing test code to work with it. Used jUnit / TestNG + WebDriver + Selenide + Masquerade bundles.

Now, in order to work with Gauge, we add the appropriate plugin in intellij IDEA. After that, it will be possible to create a new type of tests - Specification.

Now we create a specification (script) and implement the steps using the capabilities of WebDriver, Masquerade and Java.

Click on the script step and go to the implementation:

In the implementation, you can use the existing login () method.

What does this perfection look like?

Let us recall an example that we considered at the very beginning of the article:

"Navigation.openMenu(menu)” contains the implementation of opening the menu using the Masquerade library.

The library was subsequently expanded and universal steps appeared that can be used for any CUBA application. These are steps that allow you to work with program elements: buttons, fields, tables. These universal steps became the set of standard phrases that we use in BDD to write scripts.

Thanks to the Masquerade + Gauge bundle, we have significantly reduced the complexity of creating tests. Now people who have no special programming skills can write tests. The test can be written by one person (before the script was invented by one, and realized by the other, which led to confusion). So, we have achieved our goal - the interfaces are simplified, and it will not be difficult for analysts to write test scripts.

Process changes are depicted below:

It was:

It became:

In comparison, it is clear that the requirements, specification and test documentation are combined into one item. Test documentation is also an autotest, with the exception of the implementation of specific test steps.

Results

At the moment we are successfully developing in the manner indicated above. And we managed to get rid of the main problem of BDD - a serious increase in terms due to the complexity of implementation, adding and refining the toolkit. However, product quality has improved.

The time spent on supporting documentation is reduced in proportion to the number of changed specifications, since one specification change (system logic) automatically leads to a change in the autotest for one iteration. Those. The tester does not need to go into the documentation system (such as Confluence, etc.) for the update, and for other team members this is also true.

Time for the implementation and support of tests in the presence of a library that simplifies working with page objects has decreased by half, compared with work with the usual clean web-driver and the cost of reworking XP links.

In the development of any business solution and in quality management, the cost of eliminating requirements collection errors and analyzing grows exponentially . Accordingly, the likelihood of problems associated with the reworking of a product, according to existing articles and graphs in iterative development, with early detection of a problem, which is a good study of requirements, significantly reduces the cost of development, depending on the project. It can be both 0% and ~ 40%. This improvement is achieved through the introduction of BDD. This can be implemented without calling it the word BDD, but in BDD it is. Being able to work around problems is an important part of quality assurance.

In conclusion, I would like to note that this development scheme is also integrated with Continuous Integration and the test management system developed in our company - QA Lens. In QA Lens, you can write the same scenarios as in IDEA, using a domain-specific language. This language consists of a previously compiled glossary of available actions that were previously implemented. When performing an autotest on Gauge from the developer’s machine or CI, QA Lens automatically notes: which steps of the scenarios were completed and which steps were not. Thus, having banished the autotest of a script written by an analyst, the testing department immediately receives full and relevant information about the state of the product.

Authors: Sunagatov Ildar and Yushkova Yuliya ( Yushkova )