UI Test Roadmap with Kaspresso

Published in

Trendyol Tech

6 min readJan 14, 2021

“Free your muscle memory from the mundane tests you perform every single time”.

In our daily life, we always have things we do. Likewise, we have tests that we constantly run when testing the software. Now, we want to automate the tests we perform manually. There is good news concerning test automation to make it easier for testers who perform software tests manually.

In this article, we will make a roadmap for such questions: why is the UI Test needed, the useful steps to follow before writing the UI Test, and how to write the UI Test with Kaspresso? Let’s create the recipe before starting writing UI Tests.

Why has UI Test Automation become a need?

Let’s imagine that we tell a robot about the work we do routinely. For example, let’s prepare our breakfast when we wake up in the morning. What do we do? First, we check the refrigerator to see whether we have the ingredients. If the ingredients are missing, we decide to shop and if not missing, we start preparing our breakfast. We take out the plates and put what we want to eat on the plates. If there is something we want to drink, we pour it into a glass. And there, the breakfast is ready! We eat breakfast and then clean our plates. This is an action we do every day.

We say to the robot, “would you do all of these for me?’’ The robot says, “of course, just tell me what to do”, and it does that for you, but much faster. Compared to the past, we have breakfast earlier, we don’t get tired, and we spare more time for ourselves. Isn’t that great?

If we adapt the robot example to the software world, test automation is also there to facilitate the work of testers who run software tests manually.

Well, is UI Test Automation a mandatory requirement? No, it is not. However, in my opinion, it is an effective way that should be preferred. If done, we will have the following advantages:

Tests can be run more frequently,
Regression tests can be done faster,
Versions can be released earlier.

In addition, when can we continue to do manual testing?

If the application has new functionality,
If the application requires no more than one or two tests.

Decide how to write. Is it page-based or a single page?

We realized that UI Test Automation is a need and we said “We also want to automate the work we do all the time.”

Everyone may have a different method. Let’s proceed with an example. We have an e-commerce application. Homepage, listing page, listing detail page, search page, cart page, checkout page, and personal information page… We can decide to write the tests with two different methods:

We can write the scenarios of each page separately,
We can write all the scripts on a single page.

What I recommend to be preferred is to write the scenarios for each page separately. Why is that? The reason is that some scenarios can and probably will be page-specific. Other pages are not required to be concerned with them. It will help us maintain a much cleaner code structure.

Decide on the design pattern of the test code

The design pattern is how we layout the structures consisting of the properties and the relationships between them.

So, why is it necessary? Why should we decide this in our test automation process? The software development process is very complex. If we do not want to end up in a spaghetti code in this process and if we want to manage the future complexity, we need to establish a flexible structure. Thus, when writing our tests, we can easily have transitions between pages, and writing code becomes less painful.

There are multiple design patterns, my example will be with the Robot pattern. Robot pattern allows the creation of clear and understandable tests. The main aim is separating the WHAT from the HOW. You can see more details from its creator Jake Wharton.

Decide which page to start automating

Now, it is time to seek an answer to the following question: from which page should I start before starting the work? Why shouldn’t we just get to work? So, we can avoid the below questions later:

Which page scripts I handled, which pages I didn’t?
Which one was missing?
Where was I?

We need to eliminate unnecessary problems as much as possible.

Create test cases

In our e-commerce application, our users frequently perform login and register scenarios, and we often test them. Writing these pages at first is a great start!

In our scenarios, we have to consider unsuccessful situations as much as successful situations.

We test scenarios such as above.

Write UI Test Automation with Kaspresso

We made our plan and decided from which page to start. We created the scenarios for our page. Now, we can write our UI Tests.

When the gender is selected as “male” at the time of registration, the homepage is displayed with the “male” tab, and let’s write the test.

The gif on the left side is an automated UI test!

Steps:

Acceptance criteria: User not logged in.

The application opens.
Click on the account tab.
Enter email and password.
Select the gender as “male” and click the Register button.
Verify that your homepage starts in the male tab.

Import Kaspresso into the project

Create the BaseTest class

“Before” and “After” blocks are written for anything you might want to do before and after testing, respectively.

For example above, “Before” the application is built first.
“After” the data is cleared and the test is completed.

Implement the Kaspresso screen and Create screen object

The screen object extends the Kaspresso screen with KScreen, so we can use the functions provided by the Kaspresso. In the code block above; there are 2 abstract fields in KScreen that we have to override. We override layoutId and viewClass. We define the elements in the screen object. Let’s proceed with one of them. We want to reach the buttonManGender through KButton. We declare the property private because we want it to be accessible only on this page. We encapsulate the property using chooseManGender() function. We call this function in the test class when we want to click the buttonManGender button.

The ID that we use inside the withId() method, can be found in the xml file of the view.

Get the ids from the xml file

Create other screen objects that we will use in our test class

In the code block above, we created all the functions that we will use in our test class in the screen object. (AuthenticationRegisterScreen, HomeScreen and AuthenticationLoginScreen) Now, we can call them in our test class.

Write tests in the TestClass

Test classes extend the BaseTest. Thus, the functions we want to run before and after each test work. Test annotation means calling before and after annotated functions for each test. We also call the relevant functions on the relevant page in the steps of our tests.

Decide on the page to write the next UI Test

Decide what will be the next UI Test. Why is this necessary? Let’s map the next page so that we see the path ahead, and getting started doesn’t seem troublesome. Otherwise, we call into the same questions again as the path is not clear; Where should I start, Where was I?