JsonPath assertions fail to differentiate between definite and indefinite results in checks for existence [SPR-13351]

[spring-projects-issues]

Sam Brannen opened SPR-13351 and commented

Status Quo

In JsonPathExpectationsHelper, the exists() method asserts that the evaluated JsonPath expression results in a value; however, if the value is an array the exists() method throws an AssertionError if the array exists but is empty. Similarly, the doesNotExist() method does not throw an AssertionError if an array exists but is empty.

This specialized treatment for arrays is illogical and inconsistent with the treatment of empty strings and empty maps.

Analysis

It turns out that existing specialized treatment of arrays is a result of the fact that the JsonPath library always returns an empty array if the path is an indefinite path that does not evaluate to a specific result. This can be the case when a JsonPath expression uses a filter to select results based on a predicate for which there is no match in the content. Consult the discussion on what is returned when in the JsonPath documentation for details.

Deliverables

1. Ensure that empty arrays are considered existent when the JsonPath is definite but nonexistent when the JsonPath is indefinite, in line with current support for empty strings and empty maps.
2. Introduce a new mechanism for asserting that an array, map, or string is empty.
   • addressed in Introduce JsonPath matchers for empty and non-empty content [SPR-13352] #17936

---

Affects: 3.2 GA

Issue Links:

• Introduce JsonPath matchers for empty and non-empty content [SPR-13352] #17936 Introduce JsonPath matchers for empty and non-empty content ("is depended on by")
• Introduce additional JsonPath matchers in Spring MVC Test [SPR-13320] #17905 Introduce additional JsonPath matchers in Spring MVC Test

Referenced from: commits 07bb037

[spring-projects-issues]

Sam Brannen commented

The initial work for this issue was performed in conjunction with #17905 in GitHub commit 5a05cdb:

Consider empty arrays as existent in JsonPath assertions

Prior to this commit, a JsonPath assertion that a path expression evaluated to an array in JsonPathExpectationsHelper (and therefore indirectly in JsonPathResultMatchers in Spring MVC Test) would incorrectly fail if the array was present in the JSON content but empty.

This commit fixes this issue by removing the "not empty" check for arrays and lists.

[spring-projects-issues]

Sam Brannen commented

Fixed in GitHub commit 07bb037:

Differentiate b/t (in)definite results in JsonPath assertions

Prior to this commit, the exists() method in JsonPathExpectationsHelper
correctly asserted that the evaluated JsonPath expression resulted in a
value (i.e., that a non-null value exists); however, if the value was
an empty array, the exists() method always threw an AssertionError.

The existing behavior makes sense if the JsonPath expression is
'indefinite' -- for example, if the expression uses a filter to select
results based on a predicate for which there is no match in the JSON
document, but the existing behavior is illogical and therefore invalid
if the JsonPath expression is 'definite' (i.e., directly references an
array in the JSON document that exists but happens to be empty). For
example, prior to this commit, the following threw an AssertionError.

new JsonPathExpectationsHelper("$.arr").exists("{ 'arr': [] }");

Similar arguments can be made for the doesNotExist() method.

After thorough analysis of the status quo, it has become apparent that
the existing specialized treatment of arrays is a result of the fact
that the JsonPath library always returns an empty list if the path is
an 'indefinite' path that does not evaluate to a specific result.
Consult the discussion on "What is Returned When?" in the JsonPath
documentation for details:

https://github.com/jayway/JsonPath#what-is-returned-when

This commit addresses these issues by ensuring that empty arrays are
considered existent if the JsonPath expression is definite but
nonexistent if the expression is indefinite.