Make sure that the batch file is made executable depending on your OS. And match (name) contains is how you can do so: Note that match contains will not recurse any nested JSON chunks so use match contains deep instead. karate.set('temp', squares); This is the recommended, browser-agnostic approach that uses Karates core-competency as an HTTP API client i.e. The configure driver options are fine for testing on localhost and when not in headless mode. Karate will traverse sub-directories and look for *.feature files. To do that, add the following: And then the above command in Gradle would look like: The recommended way to define and run test-suites and reporting in Karate is to use the parallel runner, described in the next section. The approach in this section is more suited for troubleshooting in dev-mode, using your IDE. So in dev mode you can easily set this behavior like this. Since it is internally implemented as a JavaScript function, you can mix calls to read() freely wherever JavaScript expressions are allowed: Tip: you can even use JS expressions to dynamically choose a file based on some condition: * def someConfig = read('my-config-' + someVariable + '.json'). This is optional, and Karate will work without the logging config in place, but the default console logging may be too verbose for your needs. The DockerTarget implementation has an example and you can find more details here. You can also pass parameters into the *.feature file being called, and extract variables out of the invocation result. Note that more builder methods are available from the Runner.Builder class such as reportDir() etc. To run a script *.feature file from your Java IDE, you just need the following empty test-class in the same package. This is a core feature and does not depend on JUnit, Maven or Gradle. Will poll using the retry() settings configured. Here is an example: testCompile 'com.intuit.karate:karate-junit5:1.3.1', systemProperty "karate.options", System.properties.getProperty("karate.options"), systemProperty "karate.env", System.properties.getProperty("karate.env"), "ch.qos.logback.classic.filter.ThresholdFilter", // don't waste time waiting for a connection or if servers don't respond within 5 seconds, # steps here are executed before each Scenario in this file, # variables defined here will be 'global' to all scenarios, # and will be re-initialized before every scenario, # assigning a number (you can use '*' instead of Given / When / Then). You can always use a JavaScript function or call Java for more complex logic. As a convenience, you can call a tag directly, which is a short-cut to call another Scenario within the same feature file. Note that Content-Type had to be enclosed in quotes in the JSON above because the - (hyphen character) would cause problems otherwise. Multiple feature files (or paths) can be specified, de-limited by the space character. JsonPath filter expressions are very useful for extracting elements that meet some filter criteria out of arrays. Heres how it works for XML: This comes in useful in some cases - and avoids needing to use the set keyword or JavaScript functions to manipulate JSON. This is just a convenience short-cut for waitUntil(locator, "_.textContent.includes('" + expected + "')") since it is so frequently needed. And for dealing with binary content - see bytes. var results = scriptAll('.js-tree-browser-result-path', '_.innerText'); One limitation is that you cannot use double-quotes within these expressions, so stick to the pattern seen below. Note that the Content-Type header will be automatically set to: application/x-www-form-urlencoded. There are two types of code that can be call-ed. If you are looking for ways to do something only once per feature or across all your tests, see Hooks. When using Playwright you can omit this in which case Karate will default to Chrome (within Playwright) and the default browser window size. And as a testing framework, Karate discourages tests that give different results on every run. karate.appendTo(idxs, i); In normal programming languages, global variables are a bad thing, but for test-automation (when you know what you are doing) - this can be really convenient. Though not really recommended, you can have multiple Scenario-s within a Feature tagged with @setup. { Karate is the open source tool to combine API test automation, mockery, performance testing and even UI automation into a single framework. You can easily select (double-click), copy and paste this file: URL into your browser address bar. Karate supports JUnit 5 and the advantage is that you can have multiple methods in a test-class. And yes, relative paths will work. So you can do this, without needing the https:// part: You can also switch by page index if you know it: This sets context to a chosen frame (or