Practice English vocabulary for testing GraphQL APIs: integration tests, resolver mocking, snapshot testing, contract testing, and resolver coverage.
0 / 15 completed
1 / 15
What does 'integration test queries the schema directly' mean?
Integration tests for GraphQL execute actual query strings against the server, exercising the schema, resolvers, data loaders, and response serialization together — more realistic than unit-testing resolvers in isolation.
2 / 15
What does 'we mock the resolver in unit tests' mean?
Resolver unit tests replace actual data sources with mocks (e.g., jest.mock). This tests the resolver's business logic — field transformations, authorization checks, error handling — without needing real infrastructure.
3 / 15
What does 'the snapshot test catches schema changes' mean?
Schema snapshot tests serialize the full GraphQL schema as a string and compare it against a stored snapshot. Any unintentional schema change (added/removed type, changed field) is caught immediately, preventing accidental breaking changes.
4 / 15
What is 'schema-based contract testing' for GraphQL?
Contract testing ensures the provider (GraphQL server) and consumers (clients) agree on the schema. Tools like Pact or custom schema comparison verify that changes to the schema don't break the documented contract that clients rely on.
5 / 15
What does 'the test coverage tool reports resolver coverage' mean?
Resolver coverage tools (like graphql-coverage) analyze which resolvers are exercised by tests. Low resolver coverage means parts of the API are untested and could have bugs that only appear in production when those fields are queried.
6 / 15
Alex commented on the PR: 'I'm seeing inconsistent results when querying for user profiles. The schema test is failing intermittently, and it's difficult to reproduce.' What does 'schema-based contract testing' likely refer to in this context?
Schema-based contract testing focuses on defining a shared understanding of the GraphQL schema between client and server. This involves documenting types, fields, and relationships, often through tools or techniques that verify adherence to this documented contract. This differs from basic integration tests which primarily focus on functional behavior; schema-based testing ensures the *shape* of the data being exchanged is correct. The PR comment suggests issues with inconsistent responses, indicating a potential mismatch in expectations.
7 / 15
Maria sent this Slack message: 'Just ran the graphql-tools snapshot test and it's failing. I rolled back my changes to the resolvers but it's still failing. This is really frustrating!' What is Maria most likely experiencing?
The snapshot test is designed to detect schema changes – specifically, differences in the types and fields defined within the GraphQL schema itself. Maria's frustration indicates that her resolver code hasn't been updated to reflect these changes, leading to a discrepancy between what the schema *expects* and what the resolvers are returning. Resolvers need to be updated to align with the new schema definition – this is the core purpose of the snapshot test.
8 / 15
Ben wrote this PR description for a GraphQL mutation: 'This mutation adds a new field to the User type called updatedProfile. It takes an input object with fields like name and email.' What is the most appropriate term to describe the relationship between the mutation and the schema?
The description clearly outlines a new field added to the User type – this is fundamentally a change to the GraphQL schema. Therefore, it's most accurately described as a *schema definition*. The mutation itself triggers the resolver that handles adding the new field and its associated data, but the core relationship is defined within the schema's structure. This aligns with the concept of a 'contract' between client and server.
9 / 15
During a standup meeting, Chloe says: 'I'm using GraphQL Testing Vocabulary to ensure our resolvers handle edge cases.' What does Chloe likely mean when referring to this vocabulary?
'GraphQL Testing Vocabulary' implies a structured approach to testing resolvers, going beyond simple functional tests. It suggests Chloe is focusing on creating specific test scenarios – often involving edge cases and error handling – that define the *expected behavior* of her resolvers. This vocabulary provides the framework for these tests, ensuring consistent validation across the team.
10 / 15
David reports: 'The test coverage tool shows that only 60% of our resolver functions are covered by tests.' What is David primarily concerned about?
Test coverage measures the proportion of code executed by automated tests. A low coverage percentage (like 60%) indicates a significant portion of the resolver functions are *not* being exercised during testing. This raises concerns about potential bugs or unexpected behavior because these untested areas could contain vulnerabilities that haven't been exposed through testing – it's a key indicator for improving robustness.
11 / 15
Alex commented on the PR: 'I'm seeing inconsistent results when querying for user profiles. The schema test is failing intermittently, and it's difficult to reproduce.' What does 'schema-based contract testing' likely refer to in this context?
Schema-based contract testing focuses on defining a shared understanding of the GraphQL schema between client and server. This involves documenting types, fields, and relationships, often through tools or techniques that verify adherence to this documented contract. This differs from basic integration tests which primarily focus on functional behavior; schema-based testing ensures the *shape* of the data being exchanged is correct. The PR comment suggests issues with inconsistent responses, indicating a potential mismatch in expectations.
12 / 15
Maria sent this Slack message: 'Just ran the graphql-tools snapshot test and it's failing. I rolled back my changes to the resolvers but it's still failing. This is really frustrating!' What is Maria most likely experiencing?
The snapshot test is designed to detect schema changes – specifically, differences in the types and fields defined within the GraphQL schema itself. Maria's frustration indicates that her resolver code hasn't been updated to reflect these changes, leading to a discrepancy between what the schema *expects* and what the resolvers are returning. Resolvers need to be updated to align with the new schema definition – this is the core purpose of the snapshot test.
13 / 15
Ben wrote this PR description for a GraphQL mutation: 'This mutation adds a new field to the User type called updatedProfile. It takes an input object with fields like name and email.' What is the most appropriate term to describe the relationship between the mutation and the schema?
The description clearly outlines a new field added to the User type – this is fundamentally a change to the GraphQL schema. Therefore, it's most accurately described as a *schema definition*. The mutation itself triggers the resolver that handles adding the new field and its associated data, but the core relationship is defined within the schema's structure. This aligns with the concept of a 'contract' between client and server.
14 / 15
During a standup meeting, Chloe says: 'I'm using GraphQL Testing Vocabulary to ensure our resolvers handle edge cases.' What does Chloe likely mean when referring to this vocabulary?
'GraphQL Testing Vocabulary' implies a structured approach to testing resolvers, going beyond simple functional tests. It suggests Chloe is focusing on creating specific test scenarios – often involving edge cases and error handling – that define the *expected behavior* of her resolvers. This vocabulary provides the framework for these tests, ensuring consistent validation across the team.
15 / 15
David reports: 'The test coverage tool shows that only 60% of our resolver functions are covered by tests.' What is David primarily concerned about?
Test coverage measures the proportion of code executed by automated tests. A low coverage percentage (like 60%) indicates a significant portion of the resolver functions are *not* being exercised during testing. This raises concerns about potential bugs or unexpected behavior because these untested areas could contain vulnerabilities that haven't been exposed through testing – it's a key indicator for improving robustness.
What will I practise in "GraphQL Testing Vocabulary"?
Practice English vocabulary for testing GraphQL APIs: integration tests, resolver mocking, snapshot testing, contract testing, and resolver coverage.
How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more GraphQL & API Gateway Language exercises?
Browse the full GraphQL & API Gateway Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.