UI Testing with Karate

Reading Time: 3 minutes

Hi there,

This blog aims to throw some insight on an incredible framework for UI testing i.e Karate UI. That’s right, it is Karate. In this blog, we will explore the capabilities that Karate offers in the field of UI testing. Let’s first know what Karate really is.

What is Karate DSL?

To define Karate DSL, in simple words, we can say that it is a blend of API test-automation, mocks and performance-testing with UI-testing into a single, unified framework. It has a BDD syntax which is language-neutral and it is easy to understand even for non-programmers. This is just a simple overview of karate and there is much more to it.

Now, let’s get going to the main agenda of this blog.

What does Karate offers for UI testing?

Let’s have a look over the major capabilities of Karate UI framework.

  • Simple and easy syntax, can be understood even by non-programmers.
  • No need to learn complicated programming concepts of UI testing such as “callback” and “await”.
  • We can use wildcard and “friendly” locators without needing to inspect the HTML-page source, CSS, or internal XPath structure
  • And of course, the power of Karate’s “match” assertions can be used in UI testing also.
  • Simple retry and wait strategy, no need to have the knowledge to understand the use and the difference between implicit waits, explicit waits and fluent waits.

These points are enough in themselves which makes Karate worth to give it at-least a try. Moving on, let’s see how we can setup this framework in our local machines.

Setting up Karate UI framework.

Setting up Karate framework only for UI testing is quite easy. We would just have to add few dependencies to our pom.xml and that’s it. Of course, you would have to setup and maven project through your IDE first. Let’s have a look at out pom.xml which we have use earlier.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

Simple, isn’t it? Karate supports JUnit 5 and the advantage is that you can have multiple methods in a test-class and only 1 import is needed. Here’s an example

package karate;

import com.intuit.karate.junit5.Karate;

class SampleTest {

    Karate testSample() {
        returln Karate.run("sample").relativeTo(getClass());

You can also run your feature file directly by right clicking on it and then clicking on run, through your IDE.

Let’s have a look a basic Karate script which search “YouTube” through google and then it search Knoldus on YouTube. To say, it is a very basic and simple script, but for a new person working on karate, it will throw some insight on the usage of Karate.

Feature: Karate browser automation 

    * configure driver = { type: 'chrome' }

  Scenario: google search, land on the YouTube, and search for knoldus.

    Given driver 'https://google.com'
    And input('input[name=q]', 'Youtube')
    And click('input[name=btnK]')
    When click("h3[class='LC20lb DKV0Md']")
    Then waitForUrl('https://www.youtube.com/')
    And click('input[id=search]')
    And input('input[id=search]', 'knoldus')
    And click('button[id=search-icon-legacy]')
    And match driver.url == 'https://www.youtube.com/results?search_query=knoldus'

As you can see, you can we have use chromeDriver in the above script. Karate supports various kinds of webDrivers and you may find the whole configuration details here https://intuit.github.io/karate/karate-core/#driver-types.


If someone has worked on different UI automation tool, he/she can easily sense the standard locator text is supported in Karate and some additional locators makes it somewhat more easy in locating the elements. Like, wildcard and friendly locators. These locators make it easy to write the script, such as we have

rightOf()to right of given locator
leftOf()to left of given locator
above()above given locator
Below()below given locator
near()near given locator in any direction
Friendly Locators

Moving on, let’s explore some more features of Karate.

Code Reuse

You will often need to move steps (for e.g. a login flow) into a common feature that can be called from multiple test-scripts. You can call that login feature into your current feature file so that our test suite can become more granular and easy to handle. For example, a typical pattern would look like this

Feature: main

* call read('login.feature')

* click('#someButton')
# the rest of your flow

In this feature file we are calling an another feature file in background, which will be called before executing the scenario of main feature file.

Other than these functionalities, Karate is much more capable of doing many things. Since it is a single framework that can handle API functional, performance and UI testing, it would not be wrong to say that Karate is a powerhouse in itself. This was just tip of the iceberg, Karate can do much more like, retry() functionality, debugging, parallel execution, CI integration and much more, we just need to explore it.

Thanks, I hope you would have found this informative.



Written by 

Sparsh is a QA Consultant having experience of more than 2 years. He is familiar with the core concepts of manual and automation, Karate, Cypress, Gatling, Rest Assured and Selenium are the tools that Sparsh is familiar with. He is always eager to learn new and advanced concepts in order to upskill himself.