As mentioned above, most CI tools would be able to process the JUnit XML output of the parallel runner and determine the status of the build as well as generate reports.

The Karate Demo has a working example of the recommended parallel-runner set up. It also details how a third-party library can be easily used to generate some very nice-looking reports, from the JSON output of the parallel runner.

For example, here below is an actual report generated by the cucumber-reporting open-source library.

Another example for a popular Maven reporting plugin that is compatible with Karate JSON is Cluecumber.

The demo also features code-coverage using Jacoco, and some tips for even non-Java back-ends. Some third-party report-server solutions integrate with Karate such as ReportPortal.io.

Karate uses LOGBack which looks for a file called logback-test.xml on the 'classpath'.

Here is a sample logback-test.xml for you to get started.

You can change the com.intuit.karate logger level to INFO to reduce the amount of logging. When the level is DEBUG the entire request and response payloads are logged. If you use the above config, logs will be captured in target/karate.log.

If you want to keep the level as DEBUG (for HTML reports) but suppress logging to the console, you can comment out the STDOUT "root" appender-ref:

Or another option is to use a ThresholdFilter, so you still see critical logs on the console:

If you want to exclude the logs from your CI/CD pipeline but keep them in the execution of your users in their locals you can configure your logback using Janino. In such cases it might be desirable to have your tests using karate.logger.debug('your additional info') instead of the print keyword so you can keep logs in your pipeline in INFO.

For suppressing sensitive information such as secrets and passwords from the log and reports, see Log Masking and Report Verbosity.

The 'classpath' is a Java concept and is where some configuration files such as the one for logging are expected to be by default. If you use the Maven <test-resources> tweak described earlier (recommended), the 'root' of the classpath will be in the src/test/java folder, or else would be src/test/resources.

The only 'rule' is that on start-up Karate expects a file called karate-config.js to exist on the 'classpath' and contain a JavaScript function. The function is expected to return a JSON object and all keys and values in that JSON object will be made available as script variables.

And that’s all there is to Karate configuration ! You can easily get the value of the current 'environment' or 'profile', and then set up 'global' variables using some simple JavaScript. Here is an example:

A common requirement is to pass dynamic parameter values via the command line, and you can use the karate.properties['some.name'] syntax for getting a system property passed via JVM options in the form -Dsome.name=foo. Refer to the section on dynamic port numbers for an example.

This decision to use JavaScript for config is influenced by years of experience with the set-up of complicated test-suites and fighting with Maven profiles, Maven resource-filtering and the XML-soup that somehow gets summoned by the Maven AntRun plugin.

Karate’s approach frees you from Maven, is far more expressive, allows you to eyeball all environments in one place, and is still a plain-text file. If you want, you could even create nested chunks of JSON that 'name-space' your config variables.

This approach is indeed slightly more complicated than traditional *.properties files - but you need this complexity. Keep in mind that these are tests (not production code) and this config is going to be maintained more by the dev or QE team instead of the 'ops' or operations team.

And there is no more worrying about Maven profiles and whether the 'right' *.properties file has been copied to the proper place.

There is only one thing you need to do to switch the environment - which is to set a Java system property.

The recipe for doing this when running Maven from the command line is:

Or in Gradle:

You can refer to the documentation of the Maven Surefire Plugin for alternate ways of achieving this, but the argLine approach is the simplest and should be more than sufficient for your Continuous Integration or test-automation needs.

Here’s a reminder that running any single JUnit test via Maven can be done by:

Where CatsRunner is the JUnit class name (in any package) you wish to run.

Karate is flexible, you can easily over-write config variables within the Java or JUnit "runner" - which is very convenient when in dev-mode or rapid-prototyping.

But the recommended way is to use the karateEnv(name, value) or systemProperty(name, value) API on the parallel-runner.

For advanced users, note that tags and the karate.env environment-switch can be "linked" using the special environment tags.

When your project gets complex, you can have separate karate-config-<env>.js files that will be processed for that specific value of karate.env. This is especially useful when you want to maintain passwords, secrets or even URL-s specific for your local dev environment.

Here are the rules Karate uses on bootstrap (before every Scenario or Examples row in a Scenario Outline):

Refer to the karate demo for an example.

Karate scripts are technically in 'Gherkin' format - but all you need to grok as someone who needs to test web-services are the three sections: Feature, Background and Scenario. There can be multiple Scenario-s in a *.feature file, and at least one should be present. The Background is optional.

Lines that start with a # are comments.

Note that the parser is 'lenient' so that you don’t have to enclose all keys in double-quotes.

When asserting for expected values in JSON or XML, always prefer using match instead of assert. Match failure messages are much more descriptive and useful, and you get the power of embedded expressions and fuzzy matching.

Karate’s native support for JSON means that you can assign parts of a JSON instance into another variable, which is useful when dealing with complex response payloads.

For manipulating or updating JSON (or XML) using path expressions, refer to the set keyword.

For those who may prefer YAML as a simpler way to represent data, Karate allows you to read YAML content from a file - and it will be auto-converted into JSON.

Karate can read *.csv files and will auto-convert them to JSON. A header row is always expected. See the section on reading files - and also this example dynamic-csv.feature, which shows off the convenience of dynamic Scenario Outline-s.

In rare cases you may want to use a csv-file as-is and not auto-convert it to JSON. A good example is when you want to use a CSV file as the request-body for a file-upload. You could get by by renaming the file-extension to say *.txt but an alternative is to use the karate.readAsString() API.

JavaScript Functions are also 'native'. And yes, functions can take arguments.

Karate makes re-use of payload data, utility-functions and even other test-scripts as easy as possible. Teams typically define complicated JSON (or XML) payloads in a file and then re-use this in multiple scripts. Keywords such as set and remove allow you to to 'tweak' payload-data to fit the scenario under test. You can imagine how this greatly simplifies setting up tests for boundary conditions. And such re-use makes it easier to re-factor tests when needed, which is great for maintainability.

Reading files is achieved using the built-in JavaScript function called read(). By default, the file is expected to be in the same folder (package) and side-by-side with the *.feature file. But you can prefix the name with classpath: in which case the 'root' folder would be src/test/java (assuming you are using the recommended folder structure).

Prefer classpath: when a file is expected to be heavily re-used all across your project. And yes, relative paths will work.

You can also re-use other *.feature files from test-scripts:

When a called feature depends on some side-by-side resources such as JSON or JS files, you can use the this: prefix to ensure that relative paths work correctly - because by default Karate calculates relative paths from the "root" feature or the top-most "caller".

If a file does not end in .json, .xml, .yaml, .js, .csv or .txt, it is treated as a stream - which is typically what you would need for multipart file uploads.

For JSON and XML files, Karate will evaluate any embedded expressions on load. This enables more concise tests, and the file can be re-usable in multiple, data-driven tests.

Since it is internally implemented as a JavaScript function, you can mix calls to read() freely wherever JavaScript expressions are allowed:

And a very common need would be to use a file as the request body:

Or in a match:

The rarely used file: prefix is also supported. You could use it for 'hard-coded' absolute paths in dev mode, but is obviously not recommended for CI test-suites. A good example of where you may need this is if you programmatically write a file to the target folder, and then you can read it like this:

Karate provides a flexible way to compare two images to determine if they are the same or similar. This is especially useful when capturing screenshots during tests and comparing against baseline images that are known to be correct.

Below is a simple example that will compare a baseline image to a more recent latest image. An image comparison UI will also be embedded into the Karate HTML report with detailed information about any differences between the two images.

You can also compare images using Karate path prefixes (e.g. classpath:, this:, file:) or byte arrays:

You may configure the following image comparison options using the configure action:

Image comparison configuration options:

Examples:

Image comparison engines can also be customized:

Image comparison configuration options:

Examples:

Internally, Karate will auto-convert JSON (and even XML) to Java Map objects. And JSON arrays would become Java List-s. But you will never need to worry about this internal data-representation most of the time.

In some rare cases, for e.g. if you acquired a string from some external source, or if you generated JSON (or XML) by concatenating text or using replace, you may want to convert a string to JSON and vice-versa. You can even perform a conversion from XML to JSON if you want.

One example of when you may want to convert JSON (or XML) to a string is when you are passing a payload to custom code via Java interop. Do note that when passing JSON, the default Map and List representations should suffice for most needs (see example), and using them would avoid un-necessary string-conversion.

So you have the following type markers you can use instead of def (or the rarely used text). The first four below are best explained in this example file: type-conv.feature.

The csv and yaml types can be initialized in-line using the "triple quote" or "docstring" multi-line approach as shown here.

If you want to 'pretty print' a JSON or XML value with indenting, refer to the documentation of the print keyword.

Karate has a built-in HTML templating engine that can be used to insert additional custom HTML into the test-reports. Here is an example:

Any Karate variable will be available to the template, which is users.html in this example.

You can see what the result looks like here.

Since templates can be loaded using the classpath: prefix, you can even re-use templates across your projects via Java JAR files.

A URL remains constant until you use the url keyword again, so this is a good place to set-up the 'non-changing' parts of your REST URL-s.

A URL can take expressions, so the approach below is legal. And yes, variables can come from global config.

If you are trying to build dynamic URLs including query-string parameters in the form: http://myhost/some/path?foo=bar&search=true - please refer to the param keyword.

REST-style path parameters. Can be expressions that will be evaluated. Comma delimited values are supported which can be more convenient, and takes care of URL-encoding and appending '/' between path segments as needed.

Note that the path 'resets' after any HTTP request is made but not the url. The Hello World is a great example of 'REST-ful' use of the url when the test focuses on a single REST 'resource'. Look at how the path did not need to be specified for the second HTTP get call since /cats is part of the url.

Because Karate strips trailing slashes if part of a path parameter, if you want to append a forward-slash to the end of the URL in the final HTTP request - make sure that the last path is a single '/'.

In-line JSON:

In-line XML:

From a file in the same package. Use the classpath: prefix to load from the classpath instead.

You could always use a variable:

In most cases you won’t need to set the Content-Type header as Karate will automatically do the right thing depending on the data-type of the request.

Defining the request is mandatory if you are using an HTTP method that expects a body such as post. If you really need to have an empty body, you can use an empty string as shown below, and you can force the right Content-Type header by using the header keyword.

Sending a file as the entire binary request body is easy (note that multipart is different):

The HTTP verb - get, post, put, delete, patch, options, head, connect, trace.

Lower-case is fine.

It is worth internalizing that during test-execution, it is upon the method keyword that the actual HTTP request is issued. Which suggests that the step should be in the When form, for example: When method post. And steps that follow should logically be in the Then form. Also make sure that you complete the set up of things like url, param, header, configure etc. before you fire the method.

Although rarely needed, variable references or expressions are also supported:

This is a shortcut to assert the HTTP response code.

And this assertion will cause the test to fail if the HTTP response code is something else.

See also responseStatus if you want to do some complex assertions against the HTTP status code.

Setting query-string parameters:

The above would result in a URL like: http://myhost/mypath?someKey=hello&anotherKey=foo. Note that the ? and & will be automatically inserted.

Multi-value params are also supported:

For convenience, a null value will be ignored. You can also use JSON to set multiple query-parameters in one-line using params and this is especially useful for dynamic data-driven testing.

You can use functions or expressions:

It is worth repeating that in most cases you won’t need to set the Content-Type header as Karate will automatically do the right thing depending on the data-type of the request.

Because of how easy it is to set HTTP headers, Karate does not provide any special keywords for things like the Accept header. You simply do something like this:

A common need is to send the same header(s) for every request, and configure headers (with JSON) is how you can set this up once for all subsequent requests. And if you do this within a Background: section, it would apply to all Scenario: sections within the *.feature file.

Note that Content-Type had to be enclosed in quotes in the JSON above because the "-" (hyphen character) would cause problems otherwise. Also note that "; charset=UTF-8" would be appended to the Content-Type header that Karate sends by default, and in some rare cases, you may need to suppress this behavior completely. You can do so by setting the charset to null via the configure keyword:

If you need headers to be dynamically generated for each HTTP request, use a JavaScript function with configure headers instead of JSON.

Multi-value headers (though rarely used in the wild) are also supported:

Also look at the headers keyword which uses JSON and makes some kinds of dynamic data-driven testing easier.

Setting a cookie:

You also have the option of setting multiple cookies in one-step using the cookies keyword.

Note that any cookies returned in the HTTP response would be automatically set for any future requests. This mechanism works by calling configure cookies behind the scenes and if you need to stop auto-adding cookies for future requests, just do this:

Also refer to the built-in variable responseCookies for how you can access and perform assertions on cookie data values.

HTML form fields would be URL-encoded when the HTTP request is submitted (by the method step). You would typically use these to simulate a user sign-in and then grab a security token from the response.

Note that the Content-Type header will be automatically set to: application/x-www-form-urlencoded. You just need to do a normal POST (or GET).

For example:

A good example of the use of form field for a typical sign-in flow is this OAuth 2 demo: oauth2.feature.

Multi-values are supported the way you would expect (e.g. for simulating check-boxes and multi-selects):

You can also dynamically set multiple fields in one step using the form fields keyword.

Use this for building multipart named (form) field requests. This is typically combined with multipart file as shown below.

It is important to note that myFile above is the "field name" within the multipart/form-data request payload. This roughly corresponds to a cURL argument of -F @myFile=test.pdf.

Also note that multipart file takes a JSON argument so that you can easily set the filename and the contentType (mime-type) in one step.

When 'multipart' content is involved, the Content-Type header of the HTTP request defaults to multipart/form-data. You can over-ride it by using the header keyword before the method step. Look at multipart entity for an example.

Also refer to this demo example for a working example of multipart file uploads: upload.feature.

You can also dynamically set multiple files in one step using multipart files.

Use this for multipart content items that don’t have field-names. Here below is an example that also demonstrates using the multipart/related content-type.

params, headers, cookies, form fields, multipart fields and multipart files take a single JSON argument (which can be in-line or a variable reference), and this enables certain types of dynamic data-driven testing, especially because any JSON key with a null value will be ignored. Here is a good example in the demos: dynamic-params.feature

See also param.

See also header.

See also cookie.

See also form field.

See also multipart field.

The single JSON argument needs to be in the form { field1: { read: 'file1.ext' }, field2: { read: 'file2.ext' } } where each nested JSON is in the form expected by multipart file

For an example, refer: upload-multiple-files.feature.

The name of the SOAP action specified is used as the 'SOAPAction' header. Here is an example which also demonstrates how you could assert for expected values in the response XML.

A working example of calling a SOAP service can be found within the Karate project test-suite. Refer to the demos for another example: soap.feature.

More examples are available that showcase various ways of parameter-izing and dynamically manipulating SOAP requests in a data-driven fashion. Karate is quite flexible, and provides multiple options for you to evolve patterns that fit your environment, as you can see here: xml.feature.

Karate has built-in support for re-trying an HTTP request until a certain condition has been met. The default setting for the max retry-attempts is 3 with a poll interval of 3000 milliseconds (3 seconds). If needed, this can be changed by using configure - any time during a test, or set globally via karate-config.js

The retry keyword is designed to extend the existing method syntax (and should appear before a method step) like so:

Any JavaScript expression that uses any variable in scope can be placed after the "retry until" part. So you can refer to the response, responseStatus or even responseHeaders if needed. For example:

Refer to polling.feature for an example, and also see the alternative way to achieve polling.

You can adjust configuration settings for the HTTP client used by Karate using this keyword. The syntax is similar to def but instead of a named variable, you update configuration. Here are the configuration keys supported:

Examples:

If you need to set any of these "globally" you can easily do so using the karate object in karate-config.js - for e.g:

In rare cases where you need to add nested non-JSON data to the configure value, you have to play by the rules that apply within karate-config.js. Here is an example of performing a configure driver step in JavaScript:

Now it should be clear how Karate makes it easy to express JSON or XML. If you read from a file, the advantage is that multiple scripts can re-use the same data.

Once you have a JSON or XML object, Karate provides multiple ways to manipulate, extract or transform data. And you can easily assert that the data is as expected by comparing it with another JSON or XML object.

Game, set and match - Karate !

This is like the opposite of set if you need to remove keys or data elements from JSON or XML instances. You can even remove JSON array elements by index.

remove works for XML elements as well:

Also take a look at how a special case of embedded-expressions can remove key-value pairs from a JSON (or XML) payload: Remove if Null.

See also delete, below.

Karate provides a far more simpler and more powerful way than JSON-schema to validate the structure of a given payload. You can even mix domain and conditional validations and perform all assertions in a single step.

But first, a special short-cut for array validation needs to be introduced:

This 'in-line' short-cut for validating JSON arrays is similar to how match each works. So now, complex payloads (that include arrays) can easily be validated in one step by combining validation markers like so:

Especially note the re-use of the oddSchema both as an embedded-expression and as an array validation (on the last line).

And you can perform conditional / cross-field validations and even business-logic validations at the same time.

Refer to this for the complete example: schema-like.feature

And there is another example in the karate-demos: schema.feature where you can compare Karate’s approach with an actual JSON-schema example. You can also find a nice visual comparison and explanation here.

By now, it should be clear that link:(JsonPath can be very useful for extracting JSON 'trees' out of a given object. The get keyword allows you to save the results of a JsonPath expression for later use - which is especially useful for dynamic data-driven testing.

Karate supports the following functional-style operations via the JS API - karate.map(), karate.filter() and karate.forEach(). They can be very useful in some situations. A good example is when you have the expected data available as ready-made JSON but it is in a different "shape" from the actual data or HTTP response. There is also a karate.mapWithKey() for a common need - which is to convert an array of primitives into an array of objects, which is the form that data driven features expect.

A few more useful "transforms" are to select a sub-set of key-value pairs using karate.filterKeys(), merging 2 or more JSON-s using karate.merge() and combining 2 or more arrays (or objects) into a single array using karate.append(). And karate.appendTo() is for updating an existing variable (the equivalent of array.push() in JavaScript), which is especially useful in the body of a karate.forEach().

You can also sort arrays of arbitrary JSON using karate.sort(). Simple arrays of strings or numbers can be stripped of duplicates using karate.distinct(). All JS "native" array operations can be used, such as someName.reverse().

When handling XML, you sometimes need to call XPath functions, for example to get the count of a node-set. Any valid XPath expression is allowed on the left-hand-side of a match statement.

After every HTTP call this variable is set with the response body, and is available until the next HTTP request over-writes it. You can easily assign the whole response (or just parts of it using Json-Path or XPath) to a variable, and use it in later steps.

The response is automatically available as a JSON, XML or String object depending on what the response contents are.

As a short-cut, when running JsonPath expressions - $ represents the response. This has the advantage that you can use pure JsonPath and be more concise. For example:

And similarly for XML and XPath, '/' represents the response

The $varName form is used on the right-hand-side of Karate expressions and is slightly different from pure JsonPath expressions which always begin with $. or $[. Here is a summary of what the different 'shapes' mean in Karate:

This will always hold the contents of the response as a byte-array. This is rarely used, unless you are expecting binary content returned by the server. The match keyword will work as you expect. Here is an example: binary.feature.

The responseCookies variable is set upon any HTTP response and is a map-like (or JSON-like) object. It can be easily inspected or used in expressions.

As a convenience, cookies from the previous response are collected and passed as-is as part of the next HTTP request. This is what is normally expected and simulates a web-browser - which makes it easy to script things like HTML-form based authentication into test-flows. Refer to the documentation for cookie for details and how you can disable this if need be.

Each item within responseCookies is itself a 'map-like' object. Typically you would examine the value property as in the example above, but domain and path are also available.

See also match header which is what you would normally need.

But if you need to use values in the response headers - they will be in a variable named responseHeaders. Note that it is a 'map of lists' so you will need to do things like this:

And just as in the responseCookies example above, you can use match to run complex validations on the responseHeaders.

Finally, using karate.response.header(name) can be simpler to just get a header value string by name, and it will ignore-case for the name passed as the argument:

You would normally only need to use the status keyword. But if you really need to use the HTTP response code in an expression or save it for later, you can get it as an integer:

Note that match can give you some extra readable options:

The response time (in milliseconds) for the current response would be available in a variable called responseTime. You can use this to assert that it was returned within the expected time like so:

Karate will attempt to parse the raw HTTP response body as JSON or XML and make it available as the response value. If parsing fails, Karate will log a warning and the value of response will then be a plain string. You can still perform string comparisons such as a match contains and look for error messages etc. In rare cases, you may want to check what the "type" of the response is and it can be one of 3 different values: json, xml and string.

So if you really wanted to assert that the HTTP response body is well-formed JSON or XML you can do this:

Very rarely used - but you can get the Java system-time (for the current response) at the point when the HTTP request was initiated (the value of System.currentTimeMillis()) which can be used for detailed logging or custom framework / stats calculations.

Custom header manipulation for every HTTP request is something that Karate makes very easy and pluggable. For every HTTP request made from Karate, the internal flow is as follows:

This makes setting up of complex authentication schemes for your test-flows really easy. It typically ends up being a one-liner that appears in the Background section at the start of your test-scripts. You can re-use the function you create across your whole project.

Here is an example JavaScript function that uses some variables in the context (which have been possibly set as the result of a sign-in) to build the Authorization header. Note how even calls to Java code can be made if needed.

Assuming the above code is in a file called my-headers.js, the next section on calling other feature files shows how it looks like in action at the beginning of a test script.

Notice how once the authToken variable is initialized, it is used by the above function to generate headers for every HTTP call made as part of the test flow.

If a few steps in your flow need to temporarily change (or completely bypass) the currently-set header-manipulation scheme, just update configure headers to a new value (or set it to null) in the middle of a script. Then use the header keyword to do a custom 'over-ride' if needed.

The karate-demo has an example showing various ways to configure or set headers: headers.feature

In any complex testing endeavor, you would find yourself needing 'common' code that needs to be re-used across multiple test scripts. A typical need would be to perform a 'sign in', or create a fresh user as a pre-requisite for the scenarios being tested.

There are two types of code that can be call-ed. *.feature files and JavaScript functions.

When you have a sequence of HTTP calls that need to be repeated for multiple test scripts, Karate allows you to treat a .feature file as a re-usable unit. You can also pass parameters into the .feature file being called, and extract variables out of the invocation result.

Here is an example of using the call keyword to invoke another feature file, loaded using the read function:

The contents of my-signin.feature are shown below. A few points to note:

The above example actually makes two HTTP requests - the first is a standard 'sign-in' POST and then (for illustrative purposes) another HTTP call (a GET) is made for retrieving a list of projects for the signed-in user, and the first one is 'selected' and added to the returned 'auth token' JSON object.

So you get the picture, any kind of complicated 'sign-in' flow can be scripted and re-used.

Do look at the documentation and example for configure headers also as it goes hand-in-hand with call. In the above example, the end-result of the call to my-signin.feature resulted in the authToken variable being initialized. Take a look at how the configure headers example uses the authToken variable.

Examples of defining and using JavaScript functions appear in earlier sections of this document. Being able to define and re-use JavaScript functions is a powerful capability of Karate. For example, you can:

In real-life scripts, you would typically also use this capability of Karate to configure headers where the specified JavaScript function uses the variables that result from a sign in to manipulate headers for all subsequent HTTP requests. And it is worth mentioning that the Karate configuration 'bootstrap' routine is itself a JavaScript function.

Cucumber has a limitation where Background steps are re-run for every Scenario. And if you have a Scenario Outline, this happens for every row in the Examples. This is a problem especially for expensive, time-consuming HTTP calls, and this has been an open issue for a long time.

Karate’s callonce keyword behaves exactly like call but is guaranteed to execute only once. The results of the first call are cached, and any future calls will simply return the cached result instead of executing the JavaScript function (or feature) again and again.

This does require you to move 'set-up' into a separate *.feature (or JavaScript) file. But this totally makes sense for things not part of the 'main' test flow and which typically need to be re-usable anyway.

So when you use the combination of callonce in a Background, you can indeed get the same effect as using a @BeforeClass annotation, and you can find examples in the karate-demo, such as this one: callonce.feature.

A callonce is ideally used for only "pure" JSON. You may face issues if you attempt to mix in JS functions or Java code. See karate.callSingle().

There are a few situations where this comes in handy:

As a convenience, you can omit the eval keyword and so you can shorten the above to:

This is very convenient especially if you are calling a method on a variable that has been defined such as the karate object, and for general-purpose scripting needs such as UI automation. Note how karate.set() and karate.remove() below are used directly as a script "statement".

The built-in retry until syntax should suffice for most needs, but if you have some specific needs, this demo example (using JavaScript) should get you up and running: polling.feature.

The keywords Given When Then are only for decoration and should not be thought of as similar to an if - then - else statement. And as a testing framework, Karate discourages tests that give different results on every run.

That said, if you really need to implement 'conditional' checks, this can be one pattern:

And this is another, using karate.call(). Here we want to call a file only if a condition is satisfied:

Or if we don’t care about the result, we can eval an if statement:

And this may give you more ideas. You can always use a JavaScript function or call Java for more complex logic.

Since it is so easy to dive into Java-interop, Karate does not include any random-number functions, uuid generator or date / time utilities out of the box. You simply roll your own.

Here is an example of how to get the current date, and formatted the way you want:

And the above will result in something like this being logged: [print] 2017/10/16.

Here below are a few more common examples:

The first three are good enough for random string generation for most situations. Note that if you need to do a lot of case-insensitive string checks, karate.lowerCase() is what you are looking for.

The JS API has a karate.signal(result) method that is useful for involving asynchronous flows into a test.

Karate also has built-in support for websocket that is based on the async capability and the listen keyword. The following method signatures are available on the karate JS object to obtain a websocket client:

These will init a websocket client for the given url and optional subProtocol. You can call send() on the returned object to send a message.

If a handler function (returning a boolean) is provided - it will be used to complete the listen "wait" if true is returned. A handler function is needed only if you have to ignore some incoming traffic and stop the "wait" when a certain payload arrives. If you don’t pass a handler (or it is null), the first message is returned.

Note that karate.signal() (described as part of the listen keyword) will be called internally and the listenResult will be the payload contents of the "selected" message.

Here is an example, where the same websocket connection is used to send as well as receive a message.

Gherkin has a great way to sprinkle meta-data into test-scripts - which gives you some interesting options when running tests in bulk. The most common use-case would be to partition your tests into 'smoke', 'regression' and the like - which enables being able to selectively execute a sub-set of tests.

The documentation on how to run tests via the command line has an example of how to use tags to decide which tests to not run (or ignore). Also see first.feature and second.feature in the demos. If you find yourself juggling multiple tags with logical AND and OR complexity, refer to this Stack Overflow answer.

In situations where you start an (embedded) application server as part of the test set-up phase, a typical challenge is that the HTTP port may be determined at run-time. So how can you get this value injected into the Karate configuration ?

It so happens that the karate object has a field called properties which can read a Java system-property by name like this: karate.properties['myName']. Since the karate object is injected within karate-config.js on start-up, it is a simple and effective way for other processes within the same JVM to pass configuration values to Karate at run-time. Refer to the 'demo' karate-config.js for an example and how the demo.server.port system-property is set-up in the test runner: TestBase.java.

Karate has a set of Java API-s that expose the HTTP, JSON, data-assertion and UI automation capabilities. The primary classes are described below.

Do note that if you choose the Java API, you will naturally lose some of the test-automation framework benefits such as HTML reports, parallel execution and JavaScript / configuration. You may have to rely on unit-testing frameworks or integrate additional dependencies.

If you are looking for Cucumber 'hooks' Karate does not support them, mainly because they depend on Java code, which goes against the Karate Way™.

Instead, Karate gives you all you need as part of the syntax. Here is a summary: