enhance Json assertions reuseability

[abendt]

This is a suggested change to improve the reusability of the json matchers provided by kotest

Context

In a project we were using http4k and its associated kotest assertions. There is assertion shouldHaveBody that accepts a Matcher<String?> as parameter. Ideally we would have liked to used a matcher from kotests json module here:

request.shouldHaveBody(beEqualJson("expected")) // shouldHaveBody from http4k, beEqualJson from kotest

What we found is that the matchers from kotest are currently not very suitable for external re-use (JsonTree factory method is internal, parse method is internal, too much logic inside the shouldX functions).

Changes

We are proposing some changes here to allow easier re-use of the json matchers by external code:

• move more of the matching logic into the beX matcher for easier re-use
• re-named equalJson to beEqualJsonTree for consistency
• introduce beEqualJson that works on strings
• extract some more matchers (beJsonObject, beJsonArray, beJsonObject) from the corresponding shouldX assertions to make them re-usable

Open questions

• it seems like there is no way to construct a JsonTree outside of this module (toJsonTree is internal). should beEqualJsonTree be made internal too?

[Kantis]

I would like to keep the name equalJson over beEqualJson.
I think we can change equalJson from returning a Matcher<JsonTree> to a Matcher<String> , because as you say, there's no way to create a JsonTree outside of using the shouldX functions.

[abendt]

I would like to keep the name equalJson over beEqualJson.
I think we can change equalJson from returning a Matcher<JsonTree> to a Matcher<String> , because as you say, there's no way to create a JsonTree outside of using the shouldX functions.

i have renamed beEqualJson to equalJson and renamed beEqualJsonTree to equalJsonTree and made it private.
can i remove the old JsonTree related equalJson functions? they are not used within the codebase and are most likely not used by external code.

[sksamuel]

@Kantis you happy with this to be merged?
I think we should merge this before my PR to deprecate some older json matchers.

[Kantis]

Looks good! Sorry for taking so long @abendt