Skip to content

v0.9.5
Compare
Choose a tag to compare
@ptrthomas ptrthomas released this 16 Feb 09:25
· 2654 commits to master since this release
v0.9.5
6de466b

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.

karate-arch

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 - #755

Notable 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
  • 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 that karate.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 parallel Runner - #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 like JSON.parse() and JSON.stringify() in your JavaScript snippets. Note that you should never need to use things like JSON.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 the Runner 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:

image

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 !

Assets 4
Loading