JSONAssert VS Karate

And finally, we check that the supplied json equals to the one we got on step 3 (I use JSONAssert library here). The false boolean parameter tells to check only overlapping fields. For example, if the actual result contains the addressV2 field and the expected object doesn’t, it won’t trigger the failure. That’s a normal situation because backward compatibility data is static while the OrderCreated might grow with new parameters.

This can be improved, it'd be worth Googling for a better solution than what you have.

https://github.com/skyscreamer/JSONassert seems decent.

but it can be done from scratch in a few hours (I'd recommend this if you have 'standardized' fields which you may want to ignore):

1) Move to a matcher library for assertions (Hamcrest is decent), and abstract `toJSON` into the a matcher, rather on the input.

This would change the assertion from:

`assertEquals(toJson(someObject), giantJsonBlobFromADifferentFile)`

to:

`assertThat(someObject, jsonEqual(giantJsonBlobFromADifferentFile))`

The difference here is subtle: it allows `jsonEqual` to control the formatting of the test failure output, so on a failure you can:

* convert both of the strings back to JSON

* perform a diff, and provide the diff in the test output.

Decent blog post on the topic: https://veskoiliev.com/use-custom-hamcrest-matchers-to-level...

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

- https://insomnia.rest/ - https://hoppscotch.io/ - https://github.com/karatelabs/karate - https://github.com/warmuuh/milkman

Congrats on the launch ! I'm the lead dev of [Karate](https://github.com/karatelabs/karate) and was wondering if you had come across it. I strongly agree that collaboration should be [via Git](https://www.karatelabs.io/first-class-citizens) and the IDE and traditional solutions fall short. I hope Karate's syntax passes your "memory friendly" test :) We get regular feedback is that it is easy to read and even non-programmers can pick it up. One thing I feel we do really well is chaining of HTTP requests. And we have plugins for [IntelliJ](https://plugins.jetbrains.com/plugin/19232-karate) and [VS Code](https://marketplace.visualstudio.com/items?itemName=karatela...).

Maintaining a tool like this as open-source is hard, all the best !

FWIW https://github.com/karatelabs/karate is 83% Java.

We use karate to test our fully integrated graphql backend. Has Gherkin language support.

Try Karate

Take a look at Karate.