Test automation framework for UI testing with java

Previously I have written an article about testing API services with Java. I think that it would be a nice idea to write an article about more general test framework, which will contain parts for testing Web UI, be capable to interact with DB and has logging and advanced reporting.

I have a few requirements to test object:
- it should have Web UI and API
- it should have DB
- it should be open source and free
- deploy should be local and easy

I have chosen KanBoard because it fulfills all the requirements. KanBoard is open source, free software, which allows to create boards with tasks.

Deploy can be done with just one command, docker compose up, from the folder, which contains docker-compose.yml. For the test framework the file is put in a root folder. I will not describe how to install docker, this information can be gotten here. By default the KanBoard will be available by the link http://127.0.0.1/login , user has creds admin/admin.

The framework was written with java. Maven, Lombok, TestNG, Rest Assured, Cucumber, JDBI, Allure and Selenide are used. The framework consists of page objects; definitions, assertions and hooks; and features layers. Additionally the test framework has Config, Data generation, Shared data, API and DB components.

As an example, the user can create task test was automated. A user, a project is created by API as part of preconditions. All these entities are removed by API as part of postconditions. Additionally, the task, which is created during the test by UI interactions, is removed by API in postconditions. Creating and removing testing entities increases tests isolation and improves test’s reliability.

Config component has two classes EnvProperties and PropertiesReader. Component takes data from maven cli parameters. If a parameter is not provided, the component will take the parameter from the env.properties file. Better to get sensitive information from cli because storing sensitive information in repo is a bad practice.

Data generation component has DataProvider class and uses Faker library. Component generates objects with fake data. Id fields are exception.

Shared data has two classes SharedDataSingelton and SharedData. Sharing data between steps is a problem for cucumber. Thread Singleton can be used to solve the problem. Thread Singleton gives assurance that every thread will have just one container object, which will be used to share data.

KanBoard has untypical API, which based on HTTP. Post method, with specific application method (for example getAllProjects) inside body, is used. More information about API can be gotten by the link. API component uses modified generics approach from the previous article. The goal of the approach is to use one method, which will be typed in tests. Object representation of request and response has complicated two level structure. The first level consists of RequestWrapper and ResponseWrapper, which contains HTTP metadata (Like headers) and application data. The second level consists of APIRequestModel, APIResponseArrayModel and APIResponseEntityModel, which contains application metadata (Like jsonrpc) and data(like tasks).

DB component is used to interact with DB and get object represented results. DB component has TaskDBController, DBController and DBConnection classes. DBConnection is built with using Thread Singleton. It was done to minimize resources spends. I do not recommend to use DB component to create test data because of data consistency.

UI component is used to interact with UI. UI component consists of page objects. Wrapper methods, which searching elements by text is used because some elements do not have good locators. In real projects it is recommended to add test ids([@testId = ‘taskLabel’]) to pages instead of using searching by text.

All components are used in definitions, assertions, and hooks. It allows to separate logic and reduce duplication of code.

TestCasesRunnerForTasksFeatures is created to run tests. The class should contain path to feature files and path to steps. Additionally, scenarios method is added, which allows to run tests in parallel. Count of threads can be set up by changing threadCount option in maven surefire plugin section in pom.xml file. Local run with intellij idea requires to install cucumber plugin and modify Run configuration with two options Main class: io.cucumber.core.cli.Main, Glue: steps.hooks steps.definitions steps.assertions.

Regression.xml file is created for cli test run. Regression.xml has link to TestCasesRunnerForTasksFeatures class. Regression.xml should be added as a value to suiteXmlFile option in maven surefire plugin section in pom.xml file. After that the tests can be run with a command mvn clean test.

Allure is used as a reporting tool. Allure setting up requires to modify options argLine and allure.results.directory in maven surefire plugin section in pom.xml file. Also, allure cli should be installed. The folder target/allure-results with tests results will be created after tests run. Allure report can be deployed locally with command allure serve target/allure-results. ReportHooks is used to add screenshots.

Slf4j-simple and Rest Assured in-built functionality is used to do logging on definitions, assertions, and hooks level.

The full code can be found by the link.