Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
The 0.9.0 release is a big one. Karate no longer uses Cucumber behind the scenes and the feature-file parser and execution-engine were re-written from scratch. 100% backwards compatibility has been maintained, all your existing tests will run fine - and even IDE support has been preserved.
This took some serious engineering effort, but was totally worth it ! We can now move fast and improve the engine without worrying about the evolution of Cucumber versions. For example, the parallel-runner now executes even
Scenario-s within a
Feature in parallel, and that includes data-driven
Which leads us to the only possible breaking change you may encounter - Scenarios will be executed in parallel by default. See below.
There are absolutely no breaking changes for syntax and Java API, and it is highly likely your existing Karate tests would run as-is without any changes. But in case you have
Scenario-s that depend on each-other (which obviously is a bad-practice and absolutely NOT recommended) you will have to use the
@parallel=false tag to force them to run in sequence - when using the parallel runner. Just place the tag above the
Feature level in your test-script so that it applies to all
Scenario-s within that
Feature. Read more.
While upgrading, use this opportunity to ensure that your tests are indeed independent and can run in any order !
TestNG Support Deprecated
The documentation has always warned that JUnit is strongly recommended, and we have been announcing this deprecation in advance. This is not going to be an issue because even in the rare chance that you have gone "all in" on TestNG, the Maven surefire plugin supports JUnit and TestNG in the same project. Note that JUnit 5 support has been introduced. Keep in mind that the parallel runner (which is what you will be using most, e.g. for CI) is pure-Java and it does not matter if the runtime is JUnit or TestNG.
The next release will deprecate the
@CucumberOptions annotation and the
CucumberRunner class, please plan to switch to
com.intuit.karate.Results will eventually replace
KarateStats. All the examples and documentation have been updated. So this is the recommended pattern:
Results results = Runner.parallel(getClass(), 5); assertTrue(results.getErrorMessages(), results.getFailCount() == 0);
In fact for tests in dev mode (not the parallel runner), if you start using JUnit 5 you may not need the
@CucumberOptions) annotation any more.
On the command line, instead of
cucumber.options - you can start using
To be clear, we will only turn on deprecation warnings in the next release, the old stuff will still work in the next release (1.0) and will stop working (as per plan) only later, in the release after 1.0 - so in short, you don't need to change anything for now.
karate-netty now part of
Your existing projects are not affected, but now you no longer need to use the
karate-netty artifact if you want to use mocks or test-doubles, all of that goodness is in the main JAR itself. In other words, when you use
karate-apache, you get the test-doubles capabilities as well.
New and Notable
Already mentioned above, and there is a new HTML report that allows you to visualize the parallel efficiency: see video.
JUnit 5 support
Thanks to the JUnit team and @sormuras for his awesome support and PR-s ! You can have multiple methods in the same test-class which should reduce a lot of clutter in dev-mode. And the API is elegant, nice and DRY. Read more.
Re-vamped Karate UI
Great for demos and de-bugging tests, a big improvement is that you can even step through
call-ed features. You can import Postman collections like before, but that capability is still considered experimental. Please do contribute if you can ! See video. Read more.
Thanks to @babusekaran for some PR-s !
Lower Case and Headers
As per the HTTP spec header names should be case-insensitive. You can force all header key-values to be lower-case:
* configure lowerCaseResponseHeaders = true
We also made it easy to take any JSON and brute-force all of it to lower-case, which can be useful in some situations:
* def response = karate.lowerCase(response)
responseBytes and requestBytes
An additional built-in variable
responseBytes will hold the
response as a byte-array, useful when dealing with binary-content. And the
match syntax even works with byte-arrays, no there's no need to do a custom array comparison any more:
And match responseBytes == read('test.pdf')
Similarly, for the test-doubles /
requestBytes holds the incoming
Call Tag Selector
You can now choose a single
Scenario when using the
callonce) keyword. Just append it to the feature name like so:
call tag selector concept allows you to better compose load tests out of a large suite of existing Karate tests. Two other big improvements are the ability to customize the "report name" of any HTTP request, and to even test any Java code, not just HTTP ! As an example, see the Karate-gRPC project. Read more.
Hide steps in the report when configured or show only steps that don't begin with the
* prefix. Read more
WebSocket and Async
There are certainly not many testing frameworks that support websockets. And with just two API methods:
karate.listen(timeout) - you can easily set up tests to wait for async events such as message-queues.
Dynamic Scenario Outlines
Examples no longer have to have a fixed number of rows at run-time. Use JSON arrays, that can even be dynamic and created at run-time - but retain the same read-ability and report-friendliness of the
Scenario Outline. Read more.
CSV File Support
Karate can now read CSV files out of the box - and as you can imagine this goes really well with the Dynamic Scenario Outlines described above. So if you
read() a file with a
*.csv extension, Karate will convert it into a JSON array, and a header row is always expected. Read more.
You can now use
karate.embed(bytes, mimeType) to embed any kind of content into the test output and these would be viewable in the HTML report. Read more.
Chrome Browser Automation
You may have heard of Puppeteer and "Headless Chrome" - and guess what, Karate has first-class support for Headless Chrome now ! This sets us up for UI automation (see the next section) but - Karate is probably one of the few libraries out there that gives you the capability to save HTML from a URL you choose - into PNG or even PDF. Read more.
UI Automation (experimental)
Yes, why not - provided API testing is feature-complete and mature. We strongly feel that if we get this right, and actually solve the problem of "flaky tests", Karate would be a serious force in the world of test-automation. In our opinion, there are quite a few things that give Karate an advantage:
- clean code base, LOTs of tests, one-click git-clone and maven build dev-experience, easy for contributors
- battle-tested parallel execution, that can be easily extended into a "grid" solution in future, see video
- UI to debug and step-through tests, that we can easily extend into a record-replay "IDE" solution in future, see video
- cross-browser support from day-one, see video
- deep webdriver protocol trace-ability, see video
- Karate's regression tests for UI automation use the Karate test-doubles to serve HTML (true "dog-fooding" :), which gives us a unique advantage, for e.g. we can simulate situations like slow-loading pages with ease
- and we think one of the keys to stable and speedy UI test-automation is to move test-doubles higher in the "test pyramid" - for example, think of testing only a chunk of your UI (not the whole end-to-end) after perhaps injecting cookies and mock HTTP end-points
- since we have Gatling support, we are in a unique position to apply it in creative ways to UI testing in the future
- And Karate's assertions for JSON and XML are built-in, no extra library required
- support for Websocket that solves for Chrome (the same approach as Puppeteer) and which can be applied for tighter control over non-Chrome browsers in the future
- Unified API that solves for web, desktop and mobile - aligned with the WebDriver W3C standard, see video
The UI automation capability is deemed experimental as of now and the API can change. We are releasing this so that you can experiment and perhaps be inspired to contribute because of all the above reasons ! Read more.
Here is the complete list of all fixes and enhancements.