Karate v0.9.5 Release Notes
Release Date: 2020-02-16 // almost 4 years ago-
The Big One
๐ This took a while ! The last release was in July 2019 - but it does indicate that 0.9.4 was super-stable and that Karate for API testing is quite feature-complete. So what's new ? Web Browser Automation !
๐ฑ A lot of work went into this area, and the feedback from early adopters who used 0.9.5.RCX has been extremely encouraging. And now ๐ฅ we consider it ready for use.
๐ To know more about how Karate is different from (and better in our opinion than) the competition - please read this blog post: The world needs an alternative to Selenium - so we built one.
๐ One additional point that is going to give us an edge over other browser-automation solutions is this - because Karate embeds a web-server (via the test-doubles capability) you can submit a self-contained snippet of HTML as a full-fledged project - to demo or replicate issues. The beauty of this is that it would run completely locally, yet perfectly replicate any exotic edge case. We put a lot of thought into Karate to make it easy for developers to build, extend and maintain, and if you find any gaps in the web-browser automation - we should be able to release minor / dot-releases pretty quickly.
๐ฅ Breaking Changes
The Debugger
๐ป What we used to call the "Karate UI" (implemented in JavaFX) has been retired.
Now we have what we feel is a game-changer - a debugger which is part of the Visual Studio Code extension for Karate created by Kirk Slota. This debugger is special - it can not only step-through code, but step backwards and hot-reload code. Note that this works for any Karate test, so API and UI automation is covered. See this video of the Karate-Runner in action. Thanks also to @peterquiel who contributed syntax-coloring support to the Karate-Runner.
๐ Note that you can point the Karate-Runner to an existing Maven (or even Gradle) project, and it will work fine. The new ZIP Release is ideal for especially non-Java teams - who don't want to use Maven or Gradle.
We know of many .NET, JS and Python shops using the Karate standalone JAR - and the ZIP Release makes a very compelling case for Karate and UI automation. There is no need to compile code, and reports are built-in.
๐ง
configure abortedStepsShouldPass
You will need to be aware of this only if you use the
karate.abort()
keyword and an old version of the cucumber-reporting library - and if you want steps after an "abort" to pass - #755Notable Improvements
- โ Karate used to create a lot of log files on the file-system when running tests in parallel - and in rare cases, would exceed OS limits, not any more - #860
- 0๏ธโฃ
karate.get()
now takes a default value, which is very useful for conditional logic and "called" features where a variable has not been "pre-defined". Note thatkarate.get()
is very flexible, it can evaluate even Json-Path and XPath - not just variable references - ๐ Gatling tests would freeze in some cases, performance issues have been fixed - #845
- An
ExecutionHook
interface has been introduced for more control over the life-cycle and for teams that need to integrate with 3-rd party reporting solutions and the like, and you can inject your custom implementation via the parallelRunner
- #855 - ๐ฒ And you can now "mask" parts of the HTTP log to avoid sensitive data such as
Authorization
headers and passwords being persisted and leaked - #699 - โ Distributed Testing - that should solve for "scaling out" UI or Gatling tests
- ๐ Introducing Karate Robot (experimental) for desktop app automation and native mouse / keyboard events, you can navigate using images, see video - we know that many teams need this, there is a severe lack of solutions in this space - so please get in touch and contribute if you can !
- ๐จ
karate.log()
now "pretty prints" JSON and XML, so you don't have to resort to things likeJSON.parse()
andJSON.stringify()
in your JavaScript snippets. Note that you should never need to use things likeJSON.parse()
- and they cause problems in the long term. - There is no need to use the
@KarateOptions
annotation for the parallel runner any more. Use the "builder" methods on theRunner
class, which handles multiple features (or just directory / paths), tags, and the number of threads. Going forward, as a best-practice, you are recommended to not use the annotations any more - and if you use JUnit 5, you don't need it at all, see the example below - ๐ JUnit 5 API - a little less verbose syntax via
Karate.run()
, see below:
๐ For a list of all fixes in this release, see here.
Contributors
Thanks to @paaco, @Celeo, @peterquiel, @ghostwriternr, @sivachithambaram, @BadgerOps, @man007yadav, @Nishant-sehgal, @TamannaBhasin27, @benjaminqc, @babusekaran, @celcius112, @khanguyen88 and @kirksl for pull-requests and other contributions. You rock !