Consumer-Driven Contract Testing — Core Vocabulary
Practise core consumer-driven contract testing vocabulary: consumer, provider, pact, interaction, provider state, and the CDC philosophy.
0 / 26 completed
1 / 26
In consumer-driven contract testing, the ___ is the service that initiates API calls and defines what it expects from the API.
The consumer is the service that calls the API. In CDC, the consumer defines the contract — the minimum interactions it needs — and the provider must satisfy these expectations.
2 / 26
A ___ is the document that records the consumer's expected interactions with the provider: request formats, response structures, and status codes.
A pact (contract) is a JSON document recording all interactions the consumer expects. It includes: request method/path/headers/body and expected response status/body. The provider must verify it can fulfil each interaction.
3 / 26
In Pact, a ___ sets up a specific scenario in the provider's system before an interaction is verified — for example, 'given a user with ID 123 exists'.
A Provider State is a named precondition that the provider sets up before verifying a specific interaction. It ensures the provider database/state matches what the consumer assumed when writing its test.
4 / 26
The CDC philosophy states that the ___ defines what it needs from the API, rather than the provider dictating what it offers.
CDC inverts the traditional API ownership model: the consumer declares the minimum contract it needs, and the provider verifies it can satisfy that contract. This prevents the provider from making unilateral breaking changes.
5 / 26
Unlike integration tests, consumer-driven contract tests allow consumer and provider to be tested ___.
CDC tests allow each service to be tested independently: the consumer tests against a mock (the pact), and the provider verifies the pact without needing the consumer running. This eliminates fragile shared integration environments.
6 / 26
During a code review of a new microservice, Sarah (the consumer) is explaining her contract tests to Mark (the provider developer). She says, "I've defined a Pact that specifies I expect the payment service to return a 201 status code when I POST a payment request with a valid amount. If it doesn't, the test fails." Mark replies, 'But shouldn't *you* be telling me what response format you need? It's easier for me to just send back whatever is standard.' Which of the following best captures Sarah's approach and its rationale?
Sarah's approach directly addresses a common misconception: that the provider dictates the contract. In consumer-driven contract testing, the *consumer* (Sarah) defines what it expects from the provider based on its needs. This ensures alignment and reduces integration issues by focusing on the consumer's perspective. Mark's suggestion is outdated; the goal of CDC is to allow the consumer to drive the definition of the interaction, not the other way around.
7 / 26
During a Slack discussion about upcoming changes to the Order Service, Alex (the consumer) shares a Pact file. He explains that it details the expected response from the Inventory Service when an order is placed. He states, "This Pact ensures that the Inventory Service will always return a 200 OK status code and include the updated stock levels in the JSON payload. If either of those things aren't true, our system won't process the order." Which of the following best describes Alex's use of consumer-driven contracts?
This approach aligns with consumer-driven contract testing because Alex, as the consumer (Order Service), is defining *what* he needs from the provider (Inventory Service). The Pact documents these expectations—the status code and the included JSON data—allowing the Inventory Service to build a service that reliably meets those requirements. The wrong options incorrectly frame the Pact's purpose or suggest it should solely focus on schema validation, missing the core principle of consumer-driven specification.
8 / 26
During a standup update, David (the consumer) is discussing his team's use of consumer-driven contracts. He says, "We've created a Pact that describes the expected response from the User Service when we request a user profile. It specifies we need the full name and email address in JSON format, and a 200 OK status code. If anything else happens – like an error – our system will automatically handle it based on this contract." Which of the following best explains David's approach to testing the User Service?
David's approach exemplifies the core principle of consumer-driven contract testing: the consumer – in this case, David's team – defines what they *need* from the User Service. This contrasts with traditional integration tests where the provider dictates the API contract and consumers must adapt to it.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
9 / 26
During a code review of the Shipping Service's API, Liam (the consumer) is presenting his contract tests to Chloe (the provider developer). He shows her a Pact that outlines the expected response when a customer places an order: 'Given a valid shipping address, When the user submits the order, Then the Shipping Service should return a 201 Created status code and include the order ID in the response body.' Chloe responds, 'But shouldn't *I* be defining what data you need? I'm just fulfilling the request – why are you specifying this particular format?' Which of the following best explains Liam's approach to contract testing in this scenario?
This scenario highlights a key principle of consumer-driven contracts: the consumer defines what it *needs* from the provider's API. Liam's Pact isn't about dictating the format; it's about ensuring the Shipping Service fulfills its promise – returning a 201 status code and including the order ID. Chloe's suggestion to have the provider dictate the format would shift the responsibility onto the provider, increasing integration risk and potentially leading to mismatches between consumer expectations and provider implementation. The correct answer reflects this core dynamic.
10 / 26
During a code review of a new microservice, Sarah (the consumer) is explaining her contract tests to Mark (the provider developer). She says, "I've defined a Pact that specifies I expect the payment service to return a 201 status code when I POST a payment request with a valid amount. If it doesn't, the test fails." Mark replies, 'But shouldn't *you* be telling me what response format you need? It's easier for me to just send back whatever is standard.' Which of the following best captures Sarah's approach and its rationale?
Sarah's approach directly addresses a common misconception: that the provider dictates the contract. In consumer-driven contract testing, the *consumer* (Sarah) defines what it expects from the provider based on its needs. This ensures alignment and reduces integration issues by focusing on the consumer's perspective. Mark's suggestion is outdated; the goal of CDC is to allow the consumer to drive the definition of the interaction, not the other way around.
11 / 26
During a Slack discussion about upcoming changes to the Order Service, Alex (the consumer) shares a Pact file. He explains that it details the expected response from the Inventory Service when an order is placed. He states, "This Pact ensures that the Inventory Service will always return a 200 OK status code and include the updated stock levels in the JSON payload. If either of those things aren't true, our system won't process the order." Which of the following best describes Alex's use of consumer-driven contracts?
This approach aligns with consumer-driven contract testing because Alex, as the consumer (Order Service), is defining *what* he needs from the provider (Inventory Service). The Pact documents these expectations—the status code and the included JSON data—allowing the Inventory Service to build a service that reliably meets those requirements. The wrong options incorrectly frame the Pact's purpose or suggest it should solely focus on schema validation, missing the core principle of consumer-driven specification.
12 / 26
During a standup update, David (the consumer) is discussing his team's use of consumer-driven contracts. He says, "We've created a Pact that describes the expected response from the User Service when we request a user profile. It specifies we need the full name and email address in JSON format, and a 200 OK status code. If anything else happens – like an error – our system will automatically handle it based on this contract." Which of the following best explains David's approach to testing the User Service?
David's approach exemplifies the core principle of consumer-driven contract testing: the consumer – in this case, David's team – defines what they *need* from the User Service. This contrasts with traditional integration tests where the provider dictates the API contract and consumers must adapt to it.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
13 / 26
During a code review of the Shipping Service's API, Liam (the consumer) is presenting his contract tests to Chloe (the provider developer). He shows her a Pact that outlines the expected response when a customer places an order: 'Given a valid shipping address, When the user submits the order, Then the Shipping Service should return a 201 Created status code and include the order ID in the response body.' Chloe responds, 'But shouldn't *I* be defining what data you need? I'm just fulfilling the request – why are you specifying this particular format?' Which of the following best explains Liam's approach to contract testing in this scenario?
This scenario highlights a key principle of consumer-driven contracts: the consumer defines what it *needs* from the provider's API. Liam's Pact isn't about dictating the format; it's about ensuring the Shipping Service fulfills its promise – returning a 201 status code and including the order ID. Chloe's suggestion to have the provider dictate the format would shift the responsibility onto the provider, increasing integration risk and potentially leading to mismatches between consumer expectations and provider implementation. The correct answer reflects this core dynamic.
14 / 26
During a code review of a new microservice, Sarah (the consumer) is explaining her contract tests to Mark (the provider developer). She says, "I've defined a Pact that specifies I expect the payment service to return a 201 status code when I POST a payment request with a valid amount. If it doesn't, the test fails." Mark replies, 'But shouldn't *you* be telling me what response format you need? It's easier for me to just send back whatever is standard.' Which of the following best captures Sarah's approach and its rationale?
Sarah's approach directly addresses a common misconception: that the provider dictates the contract. In consumer-driven contract testing, the *consumer* (Sarah) defines what it expects from the provider based on its needs. This ensures alignment and reduces integration issues by focusing on the consumer's perspective. Mark's suggestion is outdated; the goal of CDC is to allow the consumer to drive the definition of the interaction, not the other way around.
15 / 26
During a Slack discussion about upcoming changes to the Order Service, Alex (the consumer) shares a Pact file. He explains that it details the expected response from the Inventory Service when an order is placed. He states, "This Pact ensures that the Inventory Service will always return a 200 OK status code and include the updated stock levels in the JSON payload. If either of those things aren't true, our system won't process the order." Which of the following best describes Alex's use of consumer-driven contracts?
This approach aligns with consumer-driven contract testing because Alex, as the consumer (Order Service), is defining *what* he needs from the provider (Inventory Service). The Pact documents these expectations—the status code and the included JSON data—allowing the Inventory Service to build a service that reliably meets those requirements. The wrong options incorrectly frame the Pact's purpose or suggest it should solely focus on schema validation, missing the core principle of consumer-driven specification.
16 / 26
During a standup update, David (the consumer) is discussing his team's use of consumer-driven contracts. He says, "We've created a Pact that describes the expected response from the User Service when we request a user profile. It specifies we need the full name and email address in JSON format, and a 200 OK status code. If anything else happens – like an error – our system will automatically handle it based on this contract." Which of the following best explains David's approach to testing the User Service?
David's approach exemplifies the core principle of consumer-driven contract testing: the consumer – in this case, David's team – defines what they *need* from the User Service. This contrasts with traditional integration tests where the provider dictates the API contract and consumers must adapt to it.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
17 / 26
During a code review of the Shipping Service's API, Liam (the consumer) is presenting his contract tests to Chloe (the provider developer). He shows her a Pact that outlines the expected response when a customer places an order: 'Given a valid shipping address, When the user submits the order, Then the Shipping Service should return a 201 Created status code and include the order ID in the response body.' Chloe responds, 'But shouldn't *I* be defining what data you need? I'm just fulfilling the request – why are you specifying this particular format?' Which of the following best explains Liam's approach to contract testing in this scenario?
This scenario highlights a key principle of consumer-driven contracts: the consumer defines what it *needs* from the provider's API. Liam's Pact isn't about dictating the format; it's about ensuring the Shipping Service fulfills its promise – returning a 201 status code and including the order ID. Chloe's suggestion to have the provider dictate the format would shift the responsibility onto the provider, increasing integration risk and potentially leading to mismatches between consumer expectations and provider implementation. The correct answer reflects this core dynamic.
18 / 26
During a code review of a new microservice, Sarah (the consumer) is explaining her contract tests to Mark (the provider developer). She says, "I've defined a Pact that specifies I expect the payment service to return a 201 status code when I POST a payment request with a valid amount. If it doesn't, the test fails." Mark replies, 'But shouldn't *you* be telling me what response format you need? It's easier for me to just send back whatever is standard.' Which of the following best captures Sarah's approach and its rationale?
Sarah's approach directly addresses a common misconception: that the provider dictates the contract. In consumer-driven contract testing, the *consumer* (Sarah) defines what it expects from the provider based on its needs. This ensures alignment and reduces integration issues by focusing on the consumer's perspective. Mark's suggestion is outdated; the goal of CDC is to allow the consumer to drive the definition of the interaction, not the other way around.
19 / 26
During a Slack discussion about upcoming changes to the Order Service, Alex (the consumer) shares a Pact file. He explains that it details the expected response from the Inventory Service when an order is placed. He states, "This Pact ensures that the Inventory Service will always return a 200 OK status code and include the updated stock levels in the JSON payload. If either of those things aren't true, our system won't process the order." Which of the following best describes Alex's use of consumer-driven contracts?
This approach aligns with consumer-driven contract testing because Alex, as the consumer (Order Service), is defining *what* he needs from the provider (Inventory Service). The Pact documents these expectations—the status code and the included JSON data—allowing the Inventory Service to build a service that reliably meets those requirements. The wrong options incorrectly frame the Pact's purpose or suggest it should solely focus on schema validation, missing the core principle of consumer-driven specification.
20 / 26
During a standup update, David (the consumer) is discussing his team's use of consumer-driven contracts. He says, "We've created a Pact that describes the expected response from the User Service when we request a user profile. It specifies we need the full name and email address in JSON format, and a 200 OK status code. If anything else happens – like an error – our system will automatically handle it based on this contract." Which of the following best explains David's approach to testing the User Service?
David's approach exemplifies the core principle of consumer-driven contract testing: the consumer – in this case, David's team – defines what they *need* from the User Service. This contrasts with traditional integration tests where the provider dictates the API contract and consumers must adapt to it.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
The correct answer emphasizes proactive definition, allowing for early issue detection and reducing the risk of unexpected changes to the User Service's API. The other options misrepresent the role of the provider or the purpose of contract testing.
21 / 26
During a code review of the Shipping Service's API, Liam (the consumer) is presenting his contract tests to Chloe (the provider developer). He shows her a Pact that outlines the expected response when a customer places an order: 'Given a valid shipping address, When the user submits the order, Then the Shipping Service should return a 201 Created status code and include the order ID in the response body.' Chloe responds, 'But shouldn't *I* be defining what data you need? I'm just fulfilling the request – why are you specifying this particular format?' Which of the following best explains Liam's approach to contract testing in this scenario?
This scenario highlights a key principle of consumer-driven contracts: the consumer defines what it *needs* from the provider's API. Liam's Pact isn't about dictating the format; it's about ensuring the Shipping Service fulfills its promise – returning a 201 status code and including the order ID. Chloe's suggestion to have the provider dictate the format would shift the responsibility onto the provider, increasing integration risk and potentially leading to mismatches between consumer expectations and provider implementation. The correct answer reflects this core dynamic.
22 / 26
During a code review of the Payment Service's API, Emily (the consumer) is explaining her contract tests to Ben (the provider developer). She presents a Pact file and says, "This Pact details the expected response when we receive a request for a transaction. Specifically, I'm asserting that the response should always include a
status_code of 200 and a transaction_id.", What is Emily primarily trying to achieve with this Pact?Emily is using the Pact to define and enforce expectations about the *structure* of the response from the Payment Service. The assertions within the Pact – like `status_code` and `transaction_id` – are ensuring that the service returns data in a predictable format. This helps catch regressions if the Payment Service's API changes without proper notification.
23 / 26
In a Slack channel discussing upcoming changes to the User Profile microservice, Maria (the consumer) sends a message: 'We're using Pact to define contracts with the Authentication Service. The Pact specifies that when we request user details, the Authentication Service *must* return an object containing
user_id and username fields.' What's the core purpose of Maria's statement regarding the Pact?Maria's message highlights the Pact's role in defining *contractual agreements* – specifically, the expected data structure. This ensures that the User Profile service can reliably consume the responses from the Authentication Service without needing to guess at the format or potentially encountering unexpected data. It prevents misinterpretations and simplifies integration.
24 / 26
Sarah (the consumer) is writing a PR description for her changes to the Order Management Service's API. She includes the following text: 'This change introduces Pact tests that validate the response from the Inventory Service when an order is placed. The Pact ensures the response always contains a
order_id and quantity field, preventing potential data inconsistencies.' What does Sarah's description primarily communicate?Sarah is explaining how Pact is being used as part of the integration testing process. She's focusing on the *contract* – the agreed-upon data structure – that's being enforced by the Pact tests. This demonstrates a proactive approach to ensuring service compatibility and preventing future issues.
25 / 26
During a daily stand-up, David (the consumer) reports: 'Our team is using Pact to ensure our Service A interacts correctly with Service B. We've created a Pact that specifies Service B *must* return an object with
product_id and price fields when we request product information.' What is the significance of David's statement in the context of consumer-driven contracts?David's statement illustrates the core principle of consumer-driven contracts: Service A (the consumer) defines what it *expects* from Service B (the provider). The Pact acts as a formal agreement on this expectation – ensuring that Service B consistently provides the necessary data fields (`product_id` and `price`) to meet Service A's needs. This promotes loose coupling and reduces integration risks.
26 / 26
Liam (the consumer) is reviewing a new service and says: 'I've defined a Pact that specifies I expect the payment service to return a
payment_id and amount field. This ensures my system can accurately record each transaction.' What is Liam primarily focused on when creating this Pact?Liam is focusing on *data contracts* – ensuring that the payment service returns information in a structured and predictable way. The `payment_id` and `amount` fields are crucial for Liam's system to correctly process transactions and maintain accurate records. This highlights the importance of defining clear expectations regarding data exchange between services.
Frequently Asked Questions
What will I practice in "Consumer-Driven Contract Testing — Core Vocabulary"?
This is an API Contract Testing exercise set. It walks through 26 scenario-based multiple-choice questions built around real usage of API Contract Testing terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 26 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the API Contract Testing vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more API Contract Testing exercises?
See the API Contract Testing exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — API Contract Testing vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.