Verify errors in GraphQlTester nested path check with Consumer

[koenpunt]

When using a nested path selection and the query throws an exception, it fails with a PathNotFoundException instead of it returning the response error.

For example, for a test with the following;

  client.documentName("TaxRateMutationSpec")
    .execute()
    .path("makeTaxRateDefault.taxRate.id").isEqualTo(taxRateId)

It would fail with:

Response has 1 unexpected error(s) of 1 total. If expected, please filter them out: [{message=The field at path '/makeTaxRateDefault/merchant' was declared as a non null type, but the code involved in retrieving data has wrongly returned a null value.  The graphql specification requires that the parent field be set to null, or if that is non nullable that it bubble up null to its parent and so on. The non-nullable type is 'Merchant' within parent type 'MakeTaxRateDefaultPayload', path=[makeTaxRateDefault, merchant], extensions={classification=NullValueInNonNullableField}}]

But when the test uses a nested path like so (rudimentary example):

  client.documentName("TaxRateMutationSpec")
    .execute()
    .path("makeTaxRateDefault.taxRate") {
       it.path("id").isEqualTo(taxRateId)
    }

The error output is:

com.jayway.jsonpath.PathNotFoundException: Expected to find an object with property ['makeTaxRateDefault'] in path $['data'] but found 'null'. This is not a json object according to the JsonProvider: 'com.jayway.jsonpath.spi.json.JacksonJsonProvider'.

I guess the response should be checked for errors before trying to parse the json?

[rstoyanchev]

The idea is that errors should be dealt with first and waived if expected via execute.errors().., as they likely imply that some or all of the data returned is missing or not according to expectations.

From the error it looks like the server returned null for the merchant sub-field, and GraphQL Java set its parent to null too so there was probably no data in the response to begin with. Rather than getting a PathNotFoundException, this highlights the underlying problem.

[koenpunt]

I know what's causing it, but I would expect the behavior to be the same.

So either a regular path match is used, or one with subpath selection, it first asserts there to be no errors before trying to access the given path.

Currently this is only true for a regular path match.

[koenpunt]

To clarify, I'm talking about unexpected responses. If a test fails due to an unexpected response, the error of the regular path matcher allows you to understand what was wrong with the response, but using the subpath matcher this information is missing.

[rstoyanchev]

Oh, I see. You're saying the error is present in both cases, but they behave differently. That's not expected and is probably why I misunderstood. The support for nested paths came later, and mistakenly didn't put the same error check.

[koenpunt]

The support for nested paths came later

I know, I proposed the feature, haha