Jackson JsonNode comparisons are broken
See original GitHub issueWhich version of Kotest are you using
5.3.1
When comparing two different JsonNode
s, shouldBe
is erroneously stating they are equal when they have different values at the same key.
Here’s a simple test that reproduces this issue for me:
@Test
fun `it should return detect differences in values`() {
val map1 = mapOf("test" to 1)
val map2 = mapOf("test" to 2)
val mapper = ObjectMapper()
val jsonNode1 = mapper.valueToTree<JsonNode>(map1)
val jsonNode2 = mapper.valueToTree<JsonNode>(map2)
// Passes
jsonNode1 shouldBe jsonNode2
// Fails with:
// expected:<"{"test":2}"> but was:<"{"test":1}">
jsonNode1.toString() shouldBe jsonNode2.toString()
}
Issue Analytics
- State:
- Created a year ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
How to compare two JsonNodes with Jackson? - Stack Overflow
I have a method which compares two objects, but I don't know how to compare JsonNode by Jackson library. I want get something...
Read more >Three ways to use Jackson for JSON in Java - Twilio
In this post I'll pick a fairly complex JSON document and three queries which I want to make using Jackson. I'll compare three...
Read more >JsonNode (jackson-databind 2.9.0 API) - FasterXML
Entry method for invoking customizable comparison, using passed-in Comparator object. Nodes will handle traversal of structured types (arrays, objects), but ...
Read more >Line-delimited JSON with Jackson - cowtowncoder
final JsonMapper mapper = new JsonMapper(); MyRequest reqOb = mapper.readValue(httpRequest.getInputStream(), MyRequest.class); // or: JsonNode ...
Read more >Introduction to JSONassert - Baeldung
Let's start our tests with a simple JSON string comparison: ... additional fields as required, without breaking the existing tests.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I tend to agree here - keeping Iterable support would seem to be the riskier long-term option, as this issue is likely to keep coming up when it surprises people. 😄
Hi,
I checked, and dropping
is Iterable
causes some tests to fail.There seems to a conceptual issue here. Kotlin iterables are defined as:
Java iterables do not have this assumption:
So while it seems idiomatic in kotlin to compare iterables by their content, it probably should not be done, because at least on the JVM platform the implementation class does not make this assumption.
My advice would be to remove the
is Iterable
check and rely on default equality check for these cases, but this decision is probably up to maintainers.