Spring GraphQL service tests: stop short of claiming an HTTP endpoint

Prove the small boundary precisely

GraphQlBoundaryContractTest builds an in-memory schema with GraphQlSource and registers data fetchers for receipt, receipts and reserve. Eight tests check selected fields, cross-tenant null, a bounded list, an oversized list error, a successful versioned mutation, stale mutation rejection, cross-tenant mutation denial and a missing required argument. Each test starts from fresh in-memory receipt values. No HTTP request, security filter, database or application component scan runs.

The tenant value is installed directly in ExecutionInput. That is useful for resolver logic, but it cannot show whether a caller can forge context through headers or a GraphQL variable. A deployed test should start the real Boot web context, send authenticated requests to the GraphQL endpoint, verify interceptor mapping, then repeat against the target repository. The broader test guide separates these layers.

Add failure tests that match the deployment

Before claiming production behavior, test persisted write races, nested-field authorization, query depth or cost limits, error redaction, request cancellation and batching under real data access. The service test provides a baseline for those integration checks; it does not substitute for them.

Checked excerpt

ExecutionResult result = source.graphQl().execute(
    ExecutionInput.newExecutionInput()
        .query("mutation { reserve(id: "RC-47", units: 7, expectedVersion: 3) { available version } }")
        .graphQLContext(Map.of("tenant", "north"))
        .build());
assertTrue(result.getErrors().isEmpty());

Verification boundary

The Java 21 / Spring Boot 4 source kit checks all eight methods in GraphQlBoundaryContractTest, with no web server or datasource.

Cost and limits

A direct schema test starts quickly and isolates field logic. Full web and database tests take longer but are required for authentication, serialization, request policy and concurrent persistence guarantees.

Common Mistakes

• Do not treat GraphQlSource execution as proof that /graphql is deployed.
• Do not treat a manually injected tenant as a verified principal.
• Do not infer database atomicity from ConcurrentHashMap behavior.

Read next

Spring tests: separate business rules, wiring and transport, Spring GraphQL tenant reads: scope every resolver before returning a record, Spring GraphQL mutation versions: reject a stale stock reservation, Spring GraphQL errors: distinguish validation, resolver failure and nullable data, Spring Security filter chain: authentication, CSRF and request order.