Scenario: "The team uses Pact for consumer-driven contract testing." What is consumer-driven contract testing?
Consumer-driven contracts: consumer generates pact file → provider verifies → both know integration is safe. Pact: most common framework. vs. integration testing: no shared environment needed.
Scenario: "The consumer pact failed provider verification." What does this mean and what is the resolution?
Failed verification — root cause types: missing field (provider removed it), changed type, unexpected status code. Resolution: should provider fix, or should the contract change?
Scenario: "We use a compatibility matrix to track which consumer version is compatible with which provider version." Why is this important?
Compatibility matrix: rows = consumer versions, columns = provider versions, cells = compatible/incompatible. "Can I deploy provider v2.3 given consumer v1.8 is in production?" Pactflow manages this with can-I-deploy.
Scenario: "The contract test uses the provider state: 'a user with ID 42 exists'." What is a provider state?
Provider states: consumer says "when X state exists, calling endpoint Y returns Z". Provider sets up state (seed test data, mock, or fixture). Enables isolated, deterministic contract tests.
Key vocab:provider state, precondition for interaction, state setup, deterministic test input.
5 / 14
Scenario: "The data engineering team applies contract testing to pipelines differently than HTTP service contracts." What is the key difference?
Data contracts in practice: dbt schema tests (column presence, type, not_null, unique, accepted_values, relationships), Soda checks for freshness/volume/distribution, Great Expectations for complex statistical rules.
Reviewer: 'I'm seeing a `ProviderResponse` in this contract test that's returning a 404. The consumer is expecting a 200! It seems like the provider isn't actually serving this endpoint, but the contract *assumes* it does. Can you double-check the provider implementation?'
Which of the following best describes the reviewer's concern regarding the contract test?
This scenario highlights a critical issue in contract testing: mismatch between expectations and reality. The reviewer isn't simply saying the consumer is wrong; they're pointing out that the *contract* is creating an illusion of functionality by assuming the provider will always return a 200, even when it doesn't. Option A is incorrect because the consumer *is* requesting a valid endpoint (based on the contract). Options B and D are less precise—the issue isn't about simulating responses or handling errors directly in the contract; it's about validating that the provider actually delivers what the contract promises.
7 / 14
Reviewer: 'I'm seeing a `ProviderResponse` in this contract test that's returning a 404. The consumer is expecting a 200! It seems like the provider isn't actually serving this endpoint, but the contract *assumes* it does. Can you double-check the provider implementation?'
Which of the following best describes the reviewer's concern regarding the contract test?
This scenario highlights a critical issue in contract testing: mismatch between expectations and reality. The reviewer isn't simply saying the consumer is wrong; they're pointing out that the *contract* is creating an illusion of functionality by assuming the provider will always return a 200, even when it doesn't. Option A is incorrect because the consumer *is* requesting a valid endpoint (based on the contract). Options B and D are less precise—the issue isn't about simulating responses or handling errors directly in the contract; it's about validating that the provider actually delivers what the contract promises.
8 / 14
Reviewer: 'I'm seeing a `ProviderResponse` in this contract test that's returning a 404. The consumer is expecting a 200! It seems like the provider isn't actually serving this endpoint, but the contract *assumes* it does. Can you double-check the provider implementation?'
Which of the following best describes the reviewer's concern regarding the contract test?
This scenario highlights a critical issue in contract testing: mismatch between expectations and reality. The reviewer isn't simply saying the consumer is wrong; they're pointing out that the *contract* is creating an illusion of functionality by assuming the provider will always return a 200, even when it doesn't. Option A is incorrect because the consumer *is* requesting a valid endpoint (based on the contract). Options B and D are less precise—the issue isn't about simulating responses or handling errors directly in the contract; it's about validating that the provider actually delivers what the contract promises.
9 / 14
Reviewer: 'I'm seeing a `ProviderResponse` in this contract test that's returning a 404. The consumer is expecting a 200! It seems like the provider isn't actually serving this endpoint, but the contract *assumes* it does. Can you double-check the provider implementation?'
Which of the following best describes the reviewer's concern regarding the contract test?
This scenario highlights a critical issue in contract testing: mismatch between expectations and reality. The reviewer isn't simply saying the consumer is wrong; they're pointing out that the *contract* is creating an illusion of functionality by assuming the provider will always return a 200, even when it doesn't. Option A is incorrect because the consumer *is* requesting a valid endpoint (based on the contract). Options B and D are less precise—the issue isn't about simulating responses or handling errors directly in the contract; it's about validating that the provider actually delivers what the contract promises.
10 / 14
During a code review of a Pact consumer contract, Sarah comments: 'I'm getting a lot of 404 errors in this test. The provider is supposed to return user details, but it's not.' What does Sarah likely mean regarding the provider and the contract?
Sarah highlights a mismatch between the contract's expectation (a 200 OK) and the actual provider behavior (404). This indicates that the consumer contract isn't adequately covering all possible scenarios—specifically, cases where the provider might not have data for a given request. The key problem here is an assumption in the contract regarding the provider's response codes.
11 / 14
In a Slack channel discussing a failing consumer contract test, Mark writes: 'The provider's state is currently set to `user_id = 123`. The consumer expects this to be present when it makes the request.' What does 'provider's state' refer to in this context?
'Provider state' in contract testing refers to a specific snapshot of data – typically within the provider – that is used as a precondition for executing a consumer contract test. This allows the consumer to verify that the provider has the required information before processing a request; it's simulating the environment the consumer expects to operate in. It's distinct from database schemas or API versions.
12 / 14
During a standup meeting, David explains that his team is using contract testing to validate the response from an external payment processor. He says, 'We're defining our expectations about the data format and values the processor will return.' What does David mean by 'defining our expectations' in this context?
When David says he's 'defining expectations,' he is essentially creating a contract (often using tools like Pact) that outlines the expected behavior of the external payment processor. This includes specifying the data format and acceptable values—essentially, what the consumer *expects* to receive from the provider. The contract then ensures these expectations are met.
13 / 14
In a PR description for a new consumer contract, Alex writes: 'This contract uses the `user_details` provider state to ensure that a user with ID 567 exists before making the API call.' What is the primary purpose of using this 'provider state' in the contract?
The 'provider state' is used to mimic the conditions that must be true *before* the consumer makes its request. By specifying a particular user (e.g., with ID 567), the contract verifies that the provider has this data available—effectively simulating a realistic scenario for testing and ensuring the consumer operates under expected conditions.
14 / 14
The team is discussing different approaches to contract testing. John states: 'We need to ensure that our consumer contract's expectations align with the provider's capabilities, regardless of whether we are using HTTP or a message queue.' What does John mean by this?
John is emphasizing a principle of *consumer-driven* contract testing: the consumer's expectations should drive the contract, irrespective of the underlying communication technology (HTTP or message queue). This ensures that the contract remains relevant and robust as the provider evolves its API. The focus is on what the consumer needs, not how the provider delivers it.
What does the "Contract Testing Vocabulary" exercise practise?
Practice consumer-driven contract testing: Pact, provider verification, consumer pact, and compatibility matrix.
How many questions are in this exercise?
This exercise has 14 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Data Contracts category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Contract Testing Vocabulary" part of a larger series?
Yes — it's one exercise in the Data Contracts category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Data Contracts category page for related exercises, or browse the main Exercises hub for other IT English topics.