MockMvcResultMatchers.jsonPath(String).value() should have a matching method to declare the expected type [SPR-14498]

[spring-projects-issues]

Chris Mercer opened SPR-14498 and commented

Java Double instances will sometimes be converted from "12.0" to "12" in JSON based on rules/Jackson configuration.

While reading the results back in testing, JsonPath will convert the "JSON number" to an Integer.

String json = "{ \"value\" : 12}";

Double expectedValue = 12.0;
MockMvcResultMatchers.jsonPath("$.value").value(expectedValue) 
...
...
... expected:<java.lang.Double> but was:<java.lang.Integer>

There should be an additional "value" method that accepts the target type for JsonPath to convert to.

Double expectedValue = 12.0;
MockMvcResultMatchers.jsonPath("$.value").value(expectedValue, Double.class) 

---

Affects: 4.2.5

Issue Links:

• MockMvcResultMatchers.jsonPath(String).value() should have a matching method to declare the expected type [SPR-16587] #21129 MockMvcResultMatchers.jsonPath(String).value() should have a matching method to declare the expected type

Referenced from: commits 2c2ce55, 7fdb892, 68463e2, d09b0fe

[spring-projects-issues]

Sam Brannen commented

FYI: This is very closely related (identical?) to a discussion on Stack Overflow.

[spring-projects-issues]

Rossen Stoyanchev commented

Currently we use JsonPath.compile(expression) to obtain a pre-compiled JsonPath and then call read(json) on it, which doesn't seem to have an option to specify the target class. Looking at the JsonPath documentation it shows examples where JsonPath.parse(json) is used first to obtain a DocumentContext on which one can then call read(expression, targetClass) with a target class. Seems like we should switch to the latter.

Sam Brannen what do you think? JsonPathExpectationsHelper currently accepts the expression as a constructor arg but whatever benefit there is, it makes no difference when used through MockMvcResultMatchers which creates a new JsonPathExpectationsHelper instance every time. So in JsonPathExpectationsHelper we could simply cache the expression and then call JsonPath.parse(json).read(expression, targetClass).

[spring-projects-issues]

Sam Brannen commented

Rossen Stoyanchev,

I agree with your proposal. That sounds like the best course of action.

By default, JsonPath will use the JsonSmartMappingProvider which has its own mapping (i.e., conversion) infrastructure based on the json-smart project. So hopefully that will suffice for most common mapping scenarios, and if it doesn't the user should be able to configure a different MappingProvider (such as the JacksonMappingProvider) as I explained in that Stack Overflow discussion.

[spring-projects-issues]

Rossen Stoyanchev commented

See commit 7fdb89 for the resulting fix.

[spring-projects-issues]

Sam Brannen commented

Great work! (y)

[spring-projects-issues]

Juergen Hoeller commented

Looks good to me. I'll backport it right away since I'm wrapping up other stuff on 4.3.x at the moment anyway :-)

[spring-projects-issues]

Sam Brannen commented

Thanks, Juergen Hoeller

[spring-projects-issues]

Sam Brannen commented

Thanks to a comment on Stack Overflow, I just noticed that...

The explicit targetType variant was added to JsonPathRequestMatchers but not to JsonPathResultMatchers.

Oops!

I'll address that in a new issue.

[spring-projects-issues]

Sam Brannen commented

See #21129