Automated tests are a key element of software development methodologies. They consist in automatically running a test code, to verify whether the application works as expected. These tests allow for a faster detection of errors and help maintain the high quality of the created system.
One of the main advantages of automated tests is their repeatability. These tests can be performed multiple times, allowing for an easy identification of issues that may arise during the development of an application.
Automated tests also allow for a faster and more effective error detection. Instead of manual testing, which is prone to human error, automated testing performs the same actions accurately and repeatedly. This means that problems can be detected faster and more often, leading to increased software quality.
At Clocklike Minds, the tests we primarily automate are those based on test scenarios. These are tests normally performed by software testers. They combine the features of functional tests, as well as those of UI tests. These are the most expensive (in terms of resources) software tests and they take a lot of time to complete, but – at the same time – they give the best results in terms of improving the quality of the application. Therefore, it is worth automating this area as much as possible.
Automated tests using external tools
Cucumber and Selenium are popular software testing tools.
Selenium is a tool for automating UI-based operations in web applications. Selenium allows for running tests on different web browsers, which makes it possible to test an application on different platforms and configurations. With the use of Selenium, one can easily simulate user interactions with the application, such as clicks, text input or page navigation.
Cucumber, on the other hand, is a software testing tool based on the Gherkin language and it is used to describe test scenarios in a way that is more understandable to humans. Thanks to this, people outside the programming world, such as business users, can create test scenarios and collaborate with the development team in the system testing process.
Cucumber and Selenium – combined together – allow for building a universal and comprehensive framework for testing applications, which – in addition – can be adjusted, as the system develops and expands. Such framework will be great for testing both simple linear business processes and very complex ones which involve many actors.
Additional noteworthy advantages of these tools include the following:
- They are open-source tools in constant development, with great documentation and a large community.
- They are “external” tools which allow us to build a framework to test web applications created in any technology. We can also create cross-platform tests, whenever various tools are used in the same business process.
- These tools work great with the Pega system. The creation of tests is supported by this system through special identifiers that we can use when designing the tests and the launch of tests is supported by Pega: they are launched automatically via the Deployment Manager – when a new version of the application is created and is being deployed to a higher environment. This is how we perform regression tests.
Gherkin
Gherkin is the language used by Cucumber. It is structured in a way that makes it readable to business users and, at the same time, allows it to describe the software’s behavior, without going into technical details of how this behavior was implemented.
The most important elements of the Gherkin language include:
- Feature File: A text file with the “feature” extension, which reflects some selected functionality of the system and includes test scenarios for this functionality.
- Feature: A keyword to describe the functionality.
- Scenario: Used to describe a specific test scenario.
- Given: A keyword used to describe the test scenario pre-conditions.
- When: A keyword used to describe the event which we want to test.
- And: A logical operator that allows you to combine conditions or test results.
- Then: A keyword to describe the expected test result.
Here’s what an example of a “feature file” looks like with one test scenario:
Feature: Test Case creation
Scenario: Sample Scenario to create a case type
Given User logs in as admin for SampleApp
When user navigates to cases explorer
And creates a new case type "Test Case"
Then the new case of type "Test Case" with status "New" should be created
At first glance, you can see the most important advantage of the Gherkin language. No additional translation of the above test scenario is needed, and you still know what it is about, what will be tested and what the expected result of the test is.
What does the implementation of automated tests look like?
This process starts quite early, with the writing of test scenarios using the Gherkin language. We can begin our work as soon as we create the business assumptions of our application, i.e. before the actual development of the system that we will be testing begins. This approach has an important advantage: sometimes it reveals various uses of the designed system that we had not considered before. The prepared test scenarios are grouped by functionality (“features”) and placed in appropriate files. This grouping is an individual matter. In Pega projects, we adopt the principle that each case type is a separate functionality.
When the first test scenarios are ready, the developer can begin their work. We use Java for our projects, which – in combination with Selenium – is perfect for automating each step of the test scenario. To put it simply, an exemplary element of a test scenario implementation may look like this:
@When("user navigates to cases explorer")
public void user_navigates_to_cases_explorer() {
webDriver.findElement(By.id("cases_explorer_menu_item").click();
}
In the above example, we create a new method where we use annotations to indicate a part of the test scenario that this method implements. Subsequently, we program the action – which, in this case, is clicking on the menu option – in the body of the method,. This is how we proceed with each line of the test script.
The last step of the deployment is to choose the test performance method. We can do it manually, through the IDE, or through one of the Maven commands. This method is useful when we want to test some selected system functionality or some specific test scenario ad-hoc. Another method employed in our projects involves the use of Jenkins, i.e., a CI/CD tool. This gives us further opportunities to automate testing, such as an automatic test launch, integration with Deployment Manager for Pega projects, the ability to run tests in parallel or advanced reporting.
Summary
Although automated tests cannot fully replace manual tests, they are worth using because of their many benefits. Here are some arguments in favor of using automated tests:
- Time saving – automated tests allow for testing a large number of test cases faster than manual tests. This saves time and allows you to focus on other tasks.
- Repeatability – automated tests can be performed many times, without the need to involve people. This allows for testing a functionality or system after each code change, and for running tests regularly, to ensure that the system is working properly.
- Reliability – automated tests are repeatable and reliable, which means that the test results are accurate and credible. Manual tests, on the other hand, are always prone to human errors that can affect their results.
- Early detection of errors – automatic tests allow for a quick detection of errors at an early stage of the software development process. This allows for problems to be identified and fixed before deploying the application to a higher environment.
It is worth noting that automated tests and manual tests complement each other and should be used together. Manual testing makes it possible to verify details that cannot be automated, and automatic tests relieve users of activities that are repetitive and, at the same time, time-consuming and costly. Organized tests provide excellent quality of the developed software.
