Karate and a Java API-testing library such as REST Assured both drive HTTP calls and assert on responses. What is written differently in a Karate project, and what does that remove?

juniormust knowfreq 72%

answer

Ask where a step's implementation lives
One artefact, not two
No step-definition layer between text and call
Keywords are Karate's own and fixed
Body and assertion inline: request, match

basics

~20 s

In Karate the test is a .feature file whose steps are the framework's own keywords, so there is no step-definition layer to write: the HTTP call, the request payload and the assertion all live in that one file.

solid answer

~50 s

A Karate test is a .feature file. Its steps — url, path, request, method, status, match — are keywords Karate itself resolves, so nothing binds a line of text to a method you wrote: there is no step-definition layer and no package of step definitions for a runner to find. A JSON body is written inline as a literal (And request { name: 'Fluffy', age: 3 }) and the assertion is a built-in step (Then match response contains { name: 'Fluffy' }) rather than a matcher chain you compose in Java. REST Assured is the opposite arrangement — the test is Java source calling a library — and a Cucumber-style suite keeps the feature file but still needs a Java method behind every line. Karate removes that middle layer; what it costs is that your test is no longer Java source.

A Karate test **is** a `.feature` file. Its steps — `url`, `path`, `request`, `method`, `status`, `match` — are keywords Karate itself resolves, so nothing binds a line of text to a method you wrote: there is no step-definition layer and no package of step definitions for a runner to find. A JSON body is written inline as a literal (`And request { name: 'Fluffy', age: 3 }`) and the assertion is a built-in step (`Then match response contains { name: 'Fluffy' }`) rather than a matcher chain you compose in Java. REST Assured is the opposite arrangement — the test is Java source calling a library — and a Cucumber-style suite keeps the feature file but still needs a Java method behind every line. Karate removes that middle layer; what it costs is that your test is no longer Java source.

code

gherkin · 16 lines

gherkin

Feature: cats

  Background:
    * url baseUrl

  Scenario: create and read a cat
    Given path 'cats'
    And request { name: 'Fluffy', age: 3 }
    When method post
    Then status 201
    * def catId = response.id

    Given path 'cats', catId
    When method get
    Then status 200
    And match response contains { name: 'Fluffy', age: 3 }

go deeper

for a junior

Remember the shape: one .feature file carries the URL, the request body and the assertion, and no Java class sits behind any line of it.

for a middle

Be able to say why nothing binds text to code. The keyword set is Karate's own and fixed, so a step is either a keyword or a JavaScript expression.

for a senior

Name the cost as fluently as the benefit: the compiler stops checking your steps, so a renamed field or a typo surfaces only when the scenario runs.

for a principal

Frame it as where the team wants its centre of gravity - one readable artefact under normal code review, against the JVM tooling a Java suite keeps.

The three arrangements

Three tools can drive the same HTTP call and assert on the same response. They differ in one structural place: where the implementation of a step lives.

Tool	Where the test lives	What binds a line to the HTTP call	What a new step costs you
Karate	a `.feature` file	one of Karate's own keywords	nothing — you reuse a keyword
REST Assured	Java source	you call the library directly	a Java method
Cucumber over a Java API library	a `.feature` file and Java source	a step definition you author	a sentence and a Java method

Karate is the only one of the three where the feature file is the complete artefact, and that is the claim the whole trade-off turns on.

Why there is nothing to bind

Karate reads feature files with its own lexer and parser, not with Cucumber's Gherkin library, and it has no step-definition registry at all. Its step vocabulary comes out of Karate's own source and is fixed: url, path, param, header, request, method, status, match, assert, def, json, xml, call, callonce, configure, retry until and a few dozen more. There is no service loader for step keywords, no annotation you can put on a class of your own, and no directory the runner scans for your code. A step is therefore one of exactly two things: a keyword Karate knows, or a JavaScript expression.

The practical effect is that a Karate project has one kind of artefact where a Cucumber-style project has two, and where a REST Assured project has Java classes that the non-Java people on the team will never open.

What the removal buys

No sentence-to-method mapping to keep in sync. A step is not a sentence somebody still has to implement; it is the implementation.
Payloads as literals. And request { name: 'Fluffy', age: 3 } is the body. Keys need no quoting, and the same shape is reused on the expected side of a match.
Assertion in the language. match is a step, not a matcher library you compose calls into. It compares whole JSON and XML documents, so the common case — "does this response look like this?" — is one line.
One file to read in review. Scenario, data and expectation are on the screen together.
A file a non-Java reader can follow. Not a specification the business writes, but a test a product person or a manual tester can read and often edit.

What it does not remove

Two things people expect to disappear and do not:

You still have a JVM project. Karate runs on the JVM, is built with Maven or Gradle, and its launcher and reports are Java. The "no code" impression is wrong.
You still write logic. Anything the keyword set does not cover — a signature, a date calculation, a loop over accounts — goes into JavaScript in the feature file, or into a Java class reached with Java.type('com.example.util.Signer').

And the cost is real. Once the test stops being Java source:

the compiler no longer checks the field names, variable names or method names in your steps;
an IDE cannot rename a variable across feature files the way it renames a Java field;
the expressions in your steps run on Karate's JavaScript engine, not under the JVM's type system;
a helper you would have written as a typed class is now a JavaScript function unless you deliberately push it back into Java.

Where a saved collection sits in this picture

A Postman collection is a third model again: the request set is a document authored in a GUI and exported as JSON, rather than source you write and review in the repository. That is not a criticism, it is a different centre of gravity, and it matters here because the argument for Karate is usually made against it. A .feature file is hand-written text that diffs and reviews like the rest of the codebase, so it falls under the same branch, review and CI rules as the service it tests. A team happy with a GUI-authored request set and a headless run in CI is not the team Karate's model is aimed at.

How to answer this in an interview

Lead with the structural difference: the feature file is the test, and no step-definition layer sits between the text and the HTTP call, because the keywords are Karate's own and fixed. Give one concrete pair — And request { ... } for the body, Then match response contains { ... } for the assertion — to show you have written one. Then name the cost in the same breath: everything the compiler used to check is now text that fails when the scenario runs. This is asked as a tool-choice question, and the answer that lands is the one that argues both sides.

## The three arrangements Three tools can drive the same HTTP call and assert on the same response. They differ in one structural place: where the **implementation** of a step lives. | Tool | Where the test lives | What binds a line to the HTTP call | What a new step costs you | |---|---|---|---| | Karate | a `.feature` file | one of Karate's own keywords | nothing — you reuse a keyword | | REST Assured | Java source | you call the library directly | a Java method | | Cucumber over a Java API library | a `.feature` file **and** Java source | a step definition you author | a sentence **and** a Java method | Karate is the only one of the three where the feature file is the complete artefact, and that is the claim the whole trade-off turns on. ## Why there is nothing to bind Karate reads feature files with its own lexer and parser, not with Cucumber's Gherkin library, and it has no step-definition registry at all. Its step vocabulary comes out of Karate's own source and is fixed: `url`, `path`, `param`, `header`, `request`, `method`, `status`, `match`, `assert`, `def`, `json`, `xml`, `call`, `callonce`, `configure`, `retry until` and a few dozen more. There is no service loader for step keywords, no annotation you can put on a class of your own, and no directory the runner scans for your code. A step is therefore one of exactly two things: a keyword Karate knows, or a JavaScript expression. The practical effect is that a Karate project has **one** kind of artefact where a Cucumber-style project has two, and where a REST Assured project has Java classes that the non-Java people on the team will never open. ## What the removal buys - **No sentence-to-method mapping to keep in sync.** A step is not a sentence somebody still has to implement; it *is* the implementation. - **Payloads as literals.** `And request { name: 'Fluffy', age: 3 }` is the body. Keys need no quoting, and the same shape is reused on the expected side of a `match`. - **Assertion in the language.** `match` is a step, not a matcher library you compose calls into. It compares whole JSON and XML documents, so the common case — "does this response look like this?" — is one line. - **One file to read in review.** Scenario, data and expectation are on the screen together. - **A file a non-Java reader can follow.** Not a specification the business writes, but a test a product person or a manual tester can read and often edit. ## What it does not remove Two things people expect to disappear and do not: 1. **You still have a JVM project.** Karate runs on the JVM, is built with Maven or Gradle, and its launcher and reports are Java. The "no code" impression is wrong. 2. **You still write logic.** Anything the keyword set does not cover — a signature, a date calculation, a loop over accounts — goes into JavaScript in the feature file, or into a Java class reached with `Java.type('com.example.util.Signer')`. And the cost is real. Once the test stops being Java source: - the compiler no longer checks the field names, variable names or method names in your steps; - an IDE cannot rename a variable across feature files the way it renames a Java field; - the expressions in your steps run on Karate's JavaScript engine, not under the JVM's type system; - a helper you would have written as a typed class is now a JavaScript function unless you deliberately push it back into Java. ## Where a saved collection sits in this picture A Postman collection is a third model again: the request set is a document authored in a GUI and exported as JSON, rather than source you write and review in the repository. That is not a criticism, it is a different centre of gravity, and it matters here because the argument for Karate is usually made against it. A `.feature` file is hand-written text that diffs and reviews like the rest of the codebase, so it falls under the same branch, review and CI rules as the service it tests. A team happy with a GUI-authored request set and a headless run in CI is not the team Karate's model is aimed at. ## How to answer this in an interview Lead with the structural difference: the feature file is the test, and no step-definition layer sits between the text and the HTTP call, because the keywords are Karate's own and fixed. Give one concrete pair — `And request { ... }` for the body, `Then match response contains { ... }` for the assertion — to show you have written one. Then name the cost in the same breath: everything the compiler used to check is now text that fails when the scenario runs. This is asked as a tool-choice question, and the answer that lands is the one that argues both sides.

Does Karate depend on Cucumber?
No. Karate parses feature files with its own lexer and parser and carries no step-definition registry — there is no `io.cucumber` dependency anywhere in the project. It can still write a Cucumber-JSON report file, which is a report format other tools consume, not a runtime dependency.
If the keyword set is fixed, how do you do something Karate has no keyword for?
Write it as JavaScript in the feature file, put it in a `.js` file the feature reads, or reach an existing Java class with `Java.type('com.example.util.Signer')`. There is no way to add a keyword — the vocabulary belongs to Karate.
What in a Karate project is still ordinary Java?
The launcher class that starts the suite, any helper classes you reach with `Java.type`, and the build file. Karate is a JVM library: the feature files are the tests, but the project around them is a normal Maven or Gradle project.

saying these in an interview costs you the question

Says Karate runs on Cucumber or needs it on the classpath
Claims Karate is codeless; it is a JVM project with JavaScript in its steps
Cannot name one Karate keyword, only the Gherkin-looking shape
Says you register your own keywords to extend Karate's vocabulary
Argues only the upside and names no cost for leaving Java source

Karate and a Java API-testing library such as REST Assured both drive HTTP calls and assert on responses. What is written differently in a Karate project, and what does that remove?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The three arrangements

Why there is nothing to bind

What the removal buys

What it does not remove

Where a saved collection sits in this picture

How to answer this in an interview

▾common follow-ups3 questions

▾red flags5 flags

The three arrangements

Why there is nothing to bind

What the removal buys

What it does not remove

Where a saved collection sits in this picture

How to answer this in an interview

answer

go deeper