Rename the implementation classes Request[Input|Output] accordingly to
match the interfaces, and move them into the support package.
Create AbstractGraphQlResponse in the support package that
pre-implements response field access.
This leaves mainly contracts in the top-level package.
See gh-332
MapGraphQlResponse is a simple wrapper around the response map exposing
it as GraphQlResponse. It is now package private and made accessible
through a static factory method on GraphQlTransport.
See gh-10
DefaultClientGraphQlResponse now parses the path to a field and creates
the same parsed representation as GraphQL Java does and uses for
GraphQLError paths. This makes it easier to correlate fields to field
errors and eliminates the need for a dependency on JSONPath in the
client.
See gh-10
Replace the use of ExecutionResult on the client side where we are
dealing with a response map rather, and also incorporate it into the
server-side hierarchy where it wraps an ExecutionResult instead.
See gh-10
GraphQlTransport returns ExecutionResult with parsed JSON so for the
most part having MappingProvider is enough. However, when a JSONPath
evaluates to String (vs Map or List), the JsonSmartJsonProvider used by
default, throws UnsupportedOperationException from toJson.
Prior to this commit, the `GraphQlTester#executeAndVerify` method would
check that an `"$.errors"` JSON path exists within the response and
contains no value.
This should fail with valid GraphQL responses, as the spec says that a
response with no error should not contain the errors map at all:
http://spec.graphql.org/draft/#sec-Errors
This commit changes the assertion and instead checks for the absence of
the errors map in the response.
Fixes gh-318
The JSON Encoder and Decoder implementations configured via
CodecConfigurer for HTTP and WebSocket are adapted to a JSONPath
MappingProvider and now automatically registered in JSONPath
configuration.
See gh-10, see gh-317
As these are expected to be used as local variables, "Spec" reduces
readability and the IDE creates variables called "spec", which
increases that effect. Given those are nested within `GraphQlClient`
and `GraphQlTester`, it makes sense to drop the spec part and local
variable names such as request and response make sense.
See gh-10, see gh-317
Extract GraphQlRequest, as a parent of RequestInput, that holds the
actual request inputs sent from the client side. RequestInput then
adds server-side transport details and ExecutionInput support.
Also replace "query" with "document" in GraphQlRequest and in
GraphQlClient.
Closes gh-310
WebOutput now exposes the ExecutionInput prepared for the request and
no longer provides access to the WebInput which is already available
to a WebInterceptor.
Closes gh-229
This commit applies the `java-test-fixtures` to the project modules and
starts moving common infrastructure to the testFixtures configuration.
See gh-217
This commit is a follow up of 2e4158c and makes the following changes:
* the id is now a mandatory attribute for `WebInput` and `RequestInput`
* a consistent IdGenerator strategy is configured for all requests
Closes gh-183
Prior to this commit, the `WebInput` would hold an `id` attribute that
correlate the request and response messages on a multiplexed connection.
This commit moves this concept directly to the `RequestInput` so that it
can be used as an `ExecutionId` for all types of transports, if
availble.
This id was already set on the `WebInput` in the WebFlux case with the
id coming from the exchange, but it also creates an id and set it for
the MVC case. This id is then propagated to GraphQL's `ExecutionInput`.
See gh-183
After the introduction of the `@GraphQlTest` annotation, this commit
adds further refinements to the testing infrastructure.
Now, `@GraphQlTest` is completely independent of any web framework and
contributes a `GraphQlTester` component.
`@SpringBootTest` integration tests with mock servers only require an
`@AutoConfigureWebGraphQlTest` to get a `WebGraphQlTester` component.
Closes gh-75
Prior to this commit, we could only test Spring GraphQL applications
with a complete application - all application and infrastructure
components were involved. While using `@SpringBootTest` is often useful
for complete integration tests (with or without a live running server),
we often want to write lean integration tests and test slices of our
application.
Just like `@WebMvcTest` or `@WebFluxTest`, this commit introduces the
support for `@GraphQlTest`. This annotation helps us to test a
particular slice of our application: a hand-picked selection of
`@Controller`, plus `RuntimeWiringConfigurer` and `WebInterceptor`
beans.
Other `@Component` must be imported or mocked for those tests.
This commit also refactors the existing auto-configuration to enable
this use case. The `WebGraphQlHandlerAutoConfiguration` now holds the
required components for `@GraphQlTest`, while other web-related
auto-configurations bring the web framework and transport
infrastructures.
Closes gh-75
Also separate RequestStrategy from WebRequestStrategy since those are
delegated to internally and never used as a hierarchy. The generics
required to make them extend from each other bring no benefit.
This commit applies the Compiler Conventions Gradle plugin to the
project modules and fix the issues raised by the compiler linter.
This commit also moves version management to the main build file for a
few dependencies, aligning the versions in the process.
It doesn't cause any issues but noticed from logging output that when
WebTestClient is used, we are serializing all of it, rather than just
the RequestInput properties.
The errorType field on GraphQLError is specific to GraphQL Java and when
serialized via GraphqlErrorHelper#toSpecification it becomes an
extension with the key "classification".
This commit ensures that we correctly deserialize back to errorType from
the "classification" extension but unfortunately that's limited to the
ErrorClassification enums that we know of.
