Skip to content

Update dependency com.intuit.karate:karate-junit5 to v1.4.1#6

Open
specmatic-builder wants to merge 1 commit intomainfrom
renovate/com.intuit.karate-karate-junit5-1.x
Open

Update dependency com.intuit.karate:karate-junit5 to v1.4.1#6
specmatic-builder wants to merge 1 commit intomainfrom
renovate/com.intuit.karate-karate-junit5-1.x

Conversation

@specmatic-builder
Copy link

@specmatic-builder specmatic-builder commented Dec 7, 2025

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
com.intuit.karate:karate-junit5 1.2.0 -> 1.4.1 age adoption passing confidence

Release Notes

karatelabs/karate (com.intuit.karate:karate-junit5)

v1.4.1

Compare Source

First, a big THANK YOU to all new contributors !

New Contributors

For those interested in participating in Hacktoberfest, you can find instructions here: Karate and Hacktoberfest

Fix List

Some notable improvements:

  • UI testing - driver.intercept() (Chrome only) now returns a mock, which opens up some advanced use-cases, see #​2361
  • some teams reported a slow down in Karate 1.4.0 especially when a lot of JS re-use was involved, which should be fixed, see #​2329

Here is a complete list of all issues fixed in this release.

Breaking Changes

The good news is that for most teams there should not be any breakages to existing test scripts. But there are a few things to note, read on below.

match each defaults to fail if array is empty

You can read a detailed description in the issue #​2364. This may break existing test scripts only if you are extensively using the fuzzy matching short-cut #[] in enbedded schema validations. The good news is that if you see any of your existing tests break, you can do this to get back the old behavior.

* configure matchEachEmptyAllowed = true

if a match each fails now with Karate 1.4.1, ensure that any JsonPath expression on the LHS (Left Hand Side) is accurate. The reason for this change in Karate behavior is that previously - if you had an invalid JsonPath expression on the LHS of a match each, it would always return an empty array, and the match would always pass.

Docker image now in karatelabs organization

Until now, the karate-chrome Docker image was published at ptrthomas/karate-chrome. It has now moved to karatelabs/karate-chrome.

IDE debugging requires extra dependency

IDE debugging now requires an extra dependency on the classpath. Maven and Gradle users can use the io.karatelabs:karate-debugserver dependency. For details on how to use the new debug-server in IntelliJ or VS Code, please refer to this wiki page: Debug Server.

Experimental Distributed Testing Support Removed

Karate used to have a distributed-testing (experimental) option released in v0.9.5. This is no-longer available as part of karate-core

Heads Up

Karate 1.5.0 will require Java 17. This is a bit sooner than we expected, but reasons are explained in #​2401 - mainly because of needing to address some CVEs. 1.4.1 may be the last release that supports Java 11.

Karate 1.5.0 will also change the Maven group-id from com.intuit.karate to io.karatelabs. Note that a 1.5.0.RC1 is available for teams to start trying this out. For a smoother transition, the Java APIs would be changed in a future release (most likely 1.6.0).

What's Changed

Full Changelog: karatelabs/karate@v1.4.0...v1.4.1

Artifacts Released

v1.4.0

Compare Source

Important

There are multiple security vulnerabilities in libraries that Karate depends on that are fixed in this release. If you are on an old version of Karate - it is strongly recommended that you upgrade. Refer #​2148 | #​2265 | #​2277

Breaking Changes

The main change in this release is that Karate requires Java 11 or above. We no longer support Java 8. Otherwise there should not be any syntax or behavior changes (from Karate 1.3.X).

Note that some of the security / CVE fixes cannot be back-ported to Java 8 because they depend on Java 11.

Also note:

  • JUnit 4 is no longer supported. If you were using JUnit 4, either move to the Runner API or JUnit 5
  • The ZIP release is no longer published since the official Karate plugins provide a better quick-start experience. The stand-alone JAR is still available.
  • The karate-mock-servlet dependency is no longer published
  • The old cucumber-java 1.2.5 dependency is no longer included, refer #​2214

Fix List

Here is a complete list of all issues fixed in this release.

What's Changed

New Contributors

Full Changelog: karatelabs/karate@v1.3.1...v1.4.0

Artifacts Released

v1.3.1

Compare Source

This is a bug-fix release.

Please refer to the release notes of v1.3.0 if you are upgrading from an older version.
  • Karate HTML report slow for large features #​1270
  • New @setup wrongly increased scenario count #​2169
  • New @setup was running even when supposed to be skipped #​2169
  • New @setup missed a way to run setup once #​2210
  • One more JS multi-threaded error solved #​2204
  • HTML report now includes karate.env #​2196
  • Better support for file-upload when files is an array #​2171
  • match each now works for contains deep #​2170
Artifacts Released

v1.3.0

Compare Source

New in 1.3.0

Visual Validation

3129-3381

A big thanks to @​jkeys089 who contributed this after exploring various commercial and open-source tools. This is designed to solve issues encountered using existing / external screenshot comparison services. For example:

  • Difficulty sharing a single set of baseline images across feature branches
    • e.g. developers working on different features will run into failures until their updates can be included in the set of baseline images
  • Hosted services are limiting for remote developers
    • e.g. it isn't possible to run screenshot comparisons without a fast, reliable internet connection
  • Hosted services have inherent limitations
    • e.g. limited number of screenshots with costly overage penalties when using commercial services
    • single-threaded performance using an OSS solution locally

The solution:

  • Run screenshot comparisons in realtime as we take them
    • even when running multi-threaded tests
  • Define comparison settings inline with the tests where the screenshots are taken
  • Review comparison results and modify screenshot settings directly in the Karate reports
  • Check-in baseline screenshots and comparison configs with the tests
    • developers can make updates in feature branches independent of other branches

Karate now has a compareImage keyword and the corresponding karate.compareImage() JS API.

Refer to this video for how to use the HTML UI in the Karate report to inspect, configure and update the screenshots.

Graal JS multi-thread issues are solved

This is a big deal, achieved after upgrading Graal to version 22.0.

Advanced users of Karate may have run into some edge cases when trying to pass a JavaScript function to called feature files, especially when callonce and karate.callSingle() are involved and tests are run in parallel.
These issues were mostly solved in 1.1.0 and 1.2.0, but a few rare cases were still reported.

This issue is finally resolved along with some code clean-up and we are back to how things were in v0.9.X. You can freely pass JS functions all over the place.

New karate.response and karate.request API

This specifically solves for retrieving a given header while ignoring the case. While Karate already had support for this in simple match statements and via the configure lowerCaseResponseHeaders option, there were advanced use-cases that required more control. You can find more details here. Here is an example:

karate.response.header('content-type').

This also makes mock request routing based on headers much easier, for e.g. karate.request.header('foo') == 'bar'.

New option to write mocks in JavaScript

This is an alternate option for those who want to write more complicated mocks and opens up a lot of possibilities. The "server side" JS API is simple, clean and designed to even serve dynamic HTML.

Refer to this documentation for more: Karate JavaScript Mocks.

contains only deep for match

This is an enhancement to match that makes it possible to assert that a JSON is "deep equal to" another - but with the slight twist that JSON array order is ignored. Come to think of it, we should have had this sooner :| This is expected to be very relevant for teams using GraphQL. Details here: #​2093

configure abortSuiteOnFailure

Some teams have requested for being able to stop the entire test suite if one test fails. This will save time when the environment has issues and "fail fast" instead of letting the CI job plough on and result in all tests failing. Details here: #​2090

Easier way to drive dynamic Scenario Outlines

See the new @setup life-cycle described below.

Breaking Changes

@setup life-cycle

This is an important change that adds a new life-cycle to scenarios. There is a description and discussion here. The updated documentation can be found here.

The highlights are:

  • adds a way for data to be set-up before a Scenario starts
  • the focus is on returning data, so no "global" state modifications are allowed, which keeps things simple
  • this was introduced specifically to make it easier to setup a JSON array (or function) for Dynamic Scenario Outlines
  • so you can think of this as a scenario that acts as a "background" for a Scenario Outline (but can also be called from any Scenario)
  • the Dynamic Scenario Outline had an inconsistency, which is that the Background was only run once, but with this change, the Background will run before every Scenario whether it is
    • a normal Scenario
    • a row from a fixed set of Examples: in a "normal" Scenario Outline:
    • or a row generated at runtime by a dynamic Scenario Outline: <-- this is the breaking change

Here is a diff of what to expect. In most cases, where you were using a Background to "drive" a dynamic Scenario Outline, the change is to use a Scenario tagged with @setup instead.

url is not passed to called features

Most likely you won't be affected by this. But in 1.2.0 we un-intentionally introduced a bug that the url and path in the HTTP "builder" behind the scenes would NOT reset when you call a feature. You can find more details here.

Some JS behavior has changed

ℹ️ Ignore this if you have not referred to JS functions within other JS functions.

For details, see: https://github.com/karatelabs/karate/issues/2009#issuecomment-1228632313

Websocket support has changed

ℹ️ Ignore this if you have not used the karate.webSocket() API

This is a breaking change, but the pattern for editing your existing tests is quite straightforward. Here below is a before-and-after:

image

  • the socket.listen(5000) call has to be replaced with * listen 5000 - where 5000 (here just an example) is the timeout in milliseconds
  • the magic-variable listenResult holds the result of the captured websocket message
  • more details are in the docs: https://github.com/karatelabs/karate/tree/develop#websocket

Heads Up

1.3.0 will be the last release of Karate that allows for usage of Java 8. From 1.4.0 onwards, Karate will have a minimum requirement of Java 11. Please comment here if you have any concerns.

For what's fixed in this version, refer to this list.

New Contributors

Full Changelog: karatelabs/karate@v1.2.0...v1.3.0

Artifacts Released

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot. Specmatic specific configuration is managed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependency renovate

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@specmatic-builder