How to design and implement an automation test case (with Karate)?

In this article, I'll show you how to design and implement an automation test case at a basic level. The framework I'll be using is Karate framework but you can use whatever framework you want, here we just want to focus on the methodology.

What is Karate?

How to pronounce	/kə'rɑ:ti/
Creator	Peter Thomas
What is it?	Karate is an automation framework that supports a variety of testing types including API test, UI test, and even Performance test. It could be considered as a single unified automation framework. The main syntax that you mainly use with Karate is Gherkin since it is built on top of Cucumber. Java and Javascript are also supported, however, the usage of them will not be very much.
Official repository and documentation	Karate is very well-documented. All detailed information and examples can be found here.
Supported languages	Gherkin, Java, Javascript

Example flow

Let's say we are testing a given endpoint as below:

URL	http://localhost:80/v1/account
Description	This endpoint to create a new (whatever) account
Method	POST
Header	Content-type: application/json
Request	{ "name": "Test", "description": "Test", "category": "Checkings", "currency": "USD" }
Response	Code: 201 { "success": true, "data": { "id": 1, "name": "Test", "description": "Test", "category": "Checkings", "balance": 0, "currency": "USD" } }
Acceptance criteria (AC)	- Request.category only accepts ["Checkings", "Savings", "Deposit"] - Request.currency only accepts ["USD", "VND"]

Design test cases

- In order to implement an automation test case, we need to design a corresponding manual test case first.

- In order to design a manual test case based on test conditions, we need to understand and know how to apply different test techniques.

- Those bullet points from AC are our test conditions, we need to design test cases to cover valid and invalid values of those 2 fields (category, currency).
▪︎ “category” has 3 possible valid values.
▪︎ “currency” has 2 possible valid values.
- For happy (positive) cases, let’s test all these test conditions together in one dedicated scenario.
- For unhappy (negative) cases, let’s create separate test cases for each target field.

Happy cases

It’s obviously that the steps are the same between different test cases, only test data is different, hence we will design only one scenario with a data table. I apply decision-table technique in this case so I can cover all valid values of each field at least once with minimum test cases. Since “category” has the most values (3), there will be at least 3 test cases.

category	currency
Checkings	USD
Savings	VND
Deposit	USD

If we want to test all combinations across these 2 fields, there will be 3 x 2 = 6 test cases in total.

category	currency
Checkings	USD
Checkings	VND
Savings	USD
Savings	VND
Deposit	USD
Deposit	VND

Now let's write our manual test case (with minimum number of test cases):

Test case	Valid account creation
Steps	Send a POST request to /v1/account endpoint: { "name": "Test", "description": "Test", "category": "{category}", "currency": "{currency}" }
Test data	category currency Checkings USD Savings VND Deposit USD
Expected	- Response code should be 201 Created. - Response.success should be true.

Negative cases

- We should not test all invalid values for all fields in one case, that way we would not know which field has caused the exception. Let’s separate them. But of course, we can still combine negative values if there’s a way to distinguish which error is caused by which input value by looking at the response.

- Therefore, I would design at least 2 test cases for each field: category, currency.

- In this example, let’s design one negative test case for "currency" field.

- Applying equivalence partitioning (EP) technique, "currency" has 2 partitions (valid partition and invalid partition). Let’s pick one value from each partition.

▪︎ Valid partition: "USD" (or "VND").
▪︎ Invalid: "KIP".

- Since valid partition has been covered in happy cases, we don’t have to test it again, just focus on invalid partition.

- Make sure to input valid values for all other fields, only "currency" will receive an invalid value.

Test case	Invalid currency
Steps	Send a POST request to /v1/account endpoint: { "name": "Test", "description": "Test", "category": "Checkings", "currency": "{currency}" }
Test data	KIP
Expected	- Response code should be 400. - Response.success should be false. - Response error message should be "Unsupported currency".

Let's implement those test cases

Now we're all set, let’s implement those test cases that we’ve designed. Since we are using Karate framework, let’s write those test cases in Gherkin syntax.

Feature: Test account creation

  Scenario Outline: Valid account creation
    * set apiRequest
      | path        | value        |
      | name        | Test         |
      | description | Test         |
      | category    | '<category>' |
      | currency    | '<currency>' |

    Given url "http://localhost:80/v1/account"
    And requset apiRequest
    And method post
    Then status 201
    * match response.success == true

    Examples:
      | category  | currency |
      | Checkings | USD      |
      | Savings   | VND      |
      | Checkings | USD      |

  Scenario Outline: Invalid currency
    * set apiRequest
      | path        | value        |
      | name        | Test         |
      | description | Test         |
      | category    | Checkings    |
      | currency    | '<currency>' |

    Given url "http://localhost:80/v1/account"
    And requset apiRequest
    And method post
    Then status 400
    * match response.success == false
    * match response.data.message == 'Unsupported currency'

    Examples:
      | currency |
      | KIP      |

Conclusion

That's it. I hope now you have a basic idea on how to deal with automation test cases from A to Z. To be a good automation QA, it's not just about writing code, it's also about having a tester mindset so you can control a full working flow all by yourself.