Quick guide on how to set up BDD test automation framework using Frameworkium

Introduction

Test automation starts to be an important part of many IT projects. In order to minimize time of manual testing, we are automating test scenarios using tools and libraries like: Selenium, Rest-Assured, Cucumber, TestNG, Junit, AssertJ and many more, depending on the language and on our needs. Connecting all of these together can sometimes be confusing and time consuming, especially for newcomers or in smaller projects, where deadlines are coming. Testing framework also needs to be maintained by engineers. Frameworkium can help to avoid or at least minimize those risks. It’s an open-source framework, which provides code structure guidelines and contains Java libraries enabling you to write tests faster without setting up your own framework. As the creators said “You don’t need to reinvent the wheel” :) It contains quick start project frameworkium-examples which utilises frameworkium-core as a framework and shows how to write tests on API and UI level. In the following article, I will propose how it can be used and how to add a BDD layer to it.

Prerequisites

Frameworkium is based on Java language, which is one of the most popular and commonly used in test automation. To speed up your work, you will need (of course it depending on you preferences):

• Java (i used version 8)
• IntelliJ
• Maven
• Gherkin plugin for IntelliJ
• Cucumber for Java plugin for IntelliJ

Setting up

Frameworkium-core is a separate project, which helps to simplify your automated tests and provides Java libraries. You don’t need to clone/copy or edit it (unless you want to submit a pull request to it). In order to add it to your new project, you will need to update the pom.xml file.

Current version of core can be found on realeses page. First of all let’s create folders structure:

As you can see, tests will need Tests Runner. Just add it in com folder.

This class is quite big, but it contains all of actions before execution of tests and before methods. It will also handle logging and running scenarios. It can be also modified or extended depending on your needs. The important thing is to pay attention to @Cucumber option section and to correctly specify the place of feature files and glue code.

The next step is to add some feature, which you would like to test. Following feature file will just implement scenario for call GET method on some API and check results and second one for basic Selenium Test.

Next step is to implement logic of our tests. In case of Selenium scenario, we need to create classes with pages, which will handle interactions with webpage and contain all locators. Let’s create GooglePage class in pages folder.

As you can see, on the top of class you can find locators. Frameworkium provides @Visible annotation. It will wait until all locators are visible and initialized on page before clicking on it. In methods, you only need to handle proper actions on elements. Of course, there is also a possibility to use webdriver directly. In order to do that, you only need to extend by BasePage class. It also gives a possibility to add wait until functions. Second class will just check and return Frameworkium page title.

Next part is to prepare rest call for second scenario. Frameworkium-core also allows us to use RestAssured library. Following request will just get information from dummy API by their id, ensure that it returns status code 200 and returns some information in JsonPath format.

Now, the code is clean and ready to use. Last part before execution is to “tie glue code” with gherkin syntax. In order to do that, you need to generate StepDefs classes from gherkin scenario. For example, you can do it by clicking on yellow bulb icon after you implement new step in gherkin scenario.

After choosing a name and path for your glue code class (I recommend dividing it per scenario or per feature depending on how complex it is), you will receive empty methods.

Now, we will just need to call methods from classes implemented before and make some assertions.

First of all, the page is open, after that new GooglePage().get() initializes page and waits for locators described by @Visible annotation. After all actions, the title of page will be checked by assertThat method, which is provided by google.truth library also included in frameworkium-core. In case of API test code will look quite similar.

Scenarios execution can be done from Test runner level or from command line by maven.

To specify which scenarios you would like to run, tags must be specified in @CucumerOptions section. It’s also important to provide proper path for glue code and features.

For maven execution, you need to run following command:

mvn clean verify -Dcucumber.options=” — tags @tagsWhichYouWantToRun”

or

mvn clean verify -Dbrowser=chrome

More examples and running options can be found on frameworkium documentation webpage.

Last but not least — logging and reporting for our tests. Each test run generates a log as defined in log4j.xml. By default logs will be pushed to /log/frameworkium.log. If you would like to write some additional information to that file it is possible by instantiating a new Logger in class from which you would like to get some additional logs E.g:

Frameworkium can use Allure reporting, which will provide nice html report for your tests. In order to use it, you will need to update a little bit pom.xml

After tests run open go to root directory of your tests using terminal and type:

mvn allure:report

This command will generate reports under \target\site\ path. Allure has many more options of configuration you can find it under documentation link. There is also a possibility to add Jenkins plugin.

Sum up

That short article is just a quick start guide on how to easily develop test automation in your team or project. Basically you only need to prepare pom.xml with a few dependencies and create runner class rest of work focused on writing tests. Of course, there are many of other possibilities and tools to do it, but I encourage you to see frameworkium documentation and try to use it and contribute.

My solution proposal can be found here. You don’t need to rewrite all screenshots :)

Pros

• No need to develop test automation framework from scratch
• Libraries included — less dependencies in pom.xml
• Open-source
• Fast and easy to use

Cons

• Frameworkium is only for Java (for some people that could be an advantage because of the fact that this is one of the most commonly used languages)
• There is no freedom to update libraries like Rest-Assured or Selenium without raising a pull request to frameworkium-core
• Limitation due to the fact that this is separate project (but there is a possibility to fork it or just raise pull request)
• Small community (but it could change)