Practice vocabulary for testing data contracts: contract violation alerts, Great Expectations, data quality assertions, and dataset contract check language.
0 / 22 completed
1 / 22
What does it mean when a system reports 'the dataset failed the contract check'?
'The dataset failed the contract check' means the data violated at least one rule defined in the data contract — such as a null constraint, type mismatch, or value range violation.
2 / 22
In Great Expectations, a '___ suite' is a named collection of expectations attached to a dataset.
Great Expectations uses the term 'expectation suite' — a named, versioned collection of expectations (rules) that can be run against a dataset to validate it against a data contract.
3 / 22
What is a 'contract violation alert'?
A contract violation alert is an automated notification — sent to the data owner or consuming team — when a dataset fails validation against its data contract, enabling fast incident response.
4 / 22
A 'data quality ___ ' is a specific, testable rule such as 'column order_id must not be null'.
A data quality assertion is a specific, boolean-testable rule. Assertions are the building blocks of data contract tests — they either pass or fail against actual data.
5 / 22
Which phrase best describes 'contract-driven testing' in a data pipeline?
Contract-driven testing means validating that data actually meets the contract's rules at pipeline checkpoints — not just that the code runs, but that the data output matches agreed expectations.
6 / 22
Reviewer: 'I'm seeing a lot of failed contract tests around the new user profile data. Specifically, we're getting alerts about inconsistent date formats and missing required fields. It looks like the API provider isn't always returning dates in ISO 8601 format, and some users aren't providing their email addresses. What does this suggest should be done to improve the robustness of our pipeline?
Options:
The correct answer highlights the importance of understanding and adapting to the contract's specifications. The alerts indicate a discrepancy between the *expected* data format (ISO 8601) and what the API provides. Simply rejecting calls or ignoring alerts is not a sustainable solution; instead, we need to implement transformations or validation within our pipeline to align with the agreed-upon contract—this demonstrates a proactive approach to data quality.
7 / 22
Reviewer: 'We've got a PR proposing changes to the user onboarding flow. The data contract tests are failing consistently – specifically, the `user_metadata` object is missing the `loyalty_program_id` field on approximately 20% of records. The test suite reports this as a 'contract violation'. What's the most appropriate response to convey the severity and next steps during a code review?
This question tests understanding of communicating the seriousness of a data contract violation in a code review context. Options A and D are dismissive and downplay the potential impact – a key aspect of data quality is ensuring accurate data for users. Option B suggests a drastic, potentially unnecessary solution; while investigation is needed, it doesn't acknowledge the specific problem identified by the tests. Option C accurately frames the issue as critical, highlights the affected users, and proposes a targeted approach to resolution (investigating the source of the missing field).
8 / 22
Reviewer: 'I'm seeing a lot of failed contract tests around the new user profile data. Specifically, we're getting alerts about inconsistent date formats and missing required fields. It looks like the API provider isn't always returning dates in ISO 8601 format, and some users aren't providing their email addresses. What does this suggest should be done to improve the robustness of our pipeline?
Options:
The correct answer highlights the importance of understanding and adapting to the contract's specifications. The alerts indicate a discrepancy between the *expected* data format (ISO 8601) and what the API provides. Simply rejecting calls or ignoring alerts is not a sustainable solution; instead, we need to implement transformations or validation within our pipeline to align with the agreed-upon contract—this demonstrates a proactive approach to data quality.
9 / 22
Reviewer: 'We've got a PR proposing changes to the user onboarding flow. The data contract tests are failing consistently – specifically, the `user_metadata` object is missing the `loyalty_program_id` field on approximately 20% of records. The test suite reports this as a 'contract violation'. What's the most appropriate response to convey the severity and next steps during a code review?
This question tests understanding of communicating the seriousness of a data contract violation in a code review context. Options A and D are dismissive and downplay the potential impact – a key aspect of data quality is ensuring accurate data for users. Option B suggests a drastic, potentially unnecessary solution; while investigation is needed, it doesn't acknowledge the specific problem identified by the tests. Option C accurately frames the issue as critical, highlights the affected users, and proposes a targeted approach to resolution (investigating the source of the missing field).
10 / 22
Reviewer: 'I'm seeing a lot of failed contract tests around the new user profile data. Specifically, we're getting alerts about inconsistent date formats and missing required fields. It looks like the API provider isn't always returning dates in ISO 8601 format, and some users aren't providing their email addresses. What does this suggest should be done to improve the robustness of our pipeline?
Options:
The correct answer highlights the importance of understanding and adapting to the contract's specifications. The alerts indicate a discrepancy between the *expected* data format (ISO 8601) and what the API provides. Simply rejecting calls or ignoring alerts is not a sustainable solution; instead, we need to implement transformations or validation within our pipeline to align with the agreed-upon contract—this demonstrates a proactive approach to data quality.
11 / 22
Reviewer: 'We've got a PR proposing changes to the user onboarding flow. The data contract tests are failing consistently – specifically, the `user_metadata` object is missing the `loyalty_program_id` field on approximately 20% of records. The test suite reports this as a 'contract violation'. What's the most appropriate response to convey the severity and next steps during a code review?
This question tests understanding of communicating the seriousness of a data contract violation in a code review context. Options A and D are dismissive and downplay the potential impact – a key aspect of data quality is ensuring accurate data for users. Option B suggests a drastic, potentially unnecessary solution; while investigation is needed, it doesn't acknowledge the specific problem identified by the tests. Option C accurately frames the issue as critical, highlights the affected users, and proposes a targeted approach to resolution (investigating the source of the missing field).
12 / 22
Reviewer: 'I'm seeing a lot of failed contract tests around the new user profile data. Specifically, we're getting alerts about inconsistent date formats and missing required fields. It looks like the API provider isn't always returning dates in ISO 8601 format, and some users aren't providing their email addresses. What does this suggest should be done to improve the robustness of our pipeline?
Options:
The correct answer highlights the importance of understanding and adapting to the contract's specifications. The alerts indicate a discrepancy between the *expected* data format (ISO 8601) and what the API provides. Simply rejecting calls or ignoring alerts is not a sustainable solution; instead, we need to implement transformations or validation within our pipeline to align with the agreed-upon contract—this demonstrates a proactive approach to data quality.
13 / 22
Reviewer: 'We've got a PR proposing changes to the user onboarding flow. The data contract tests are failing consistently – specifically, the `user_metadata` object is missing the `loyalty_program_id` field on approximately 20% of records. The test suite reports this as a 'contract violation'. What's the most appropriate response to convey the severity and next steps during a code review?
This question tests understanding of communicating the seriousness of a data contract violation in a code review context. Options A and D are dismissive and downplay the potential impact – a key aspect of data quality is ensuring accurate data for users. Option B suggests a drastic, potentially unnecessary solution; while investigation is needed, it doesn't acknowledge the specific problem identified by the tests. Option C accurately frames the issue as critical, highlights the affected users, and proposes a targeted approach to resolution (investigating the source of the missing field).
14 / 22
Reviewer: 'The data contract tests are failing consistently – specifically, the `user_profile` object is not validating against the schema. This suggests a mismatch between the expected structure of the incoming data and the defined contract. What's the most appropriate response to this code review comment?'
The core of contract testing is ensuring alignment between expectations and reality. The reviewer's comment points to a potential schema mismatch – this is the most likely root cause. Options A and D are incorrect because they assume malicious intent or dismiss the validity of the tests; option C is premature without understanding the source of the problem, and option B focuses on blaming rather than investigation.
15 / 22
Slack message from Sarah: 'I've run the data contract tests after integrating the new customer data source. The results show a significant number of failures related to string length validation. It seems the API is returning customer names longer than 25 characters, which isn't defined in our contract. How should I best communicate this issue to the team?'
Sarah's message highlights a specific contract violation. The best response is to acknowledge the issue and request help – this demonstrates collaboration and focuses on finding a solution. A detailed report (option 1) would be overwhelming, option 3 is potentially premature without understanding impact, and option 4 is highly irresponsible given the failing tests.
16 / 22
During a code review, John mentions that 'the dataset failed the contract check.' What does this typically indicate?
This phrase refers to a validation process. A 'failed contract check' means the incoming data doesn't meet the specifications outlined in the data contract – likely related to schema validation and expected data types. It's not about corruption or server overload; those are separate issues.
17 / 22
As a lead engineer, you receive this Slack message from David: 'I've run the data contract tests after integrating the new product catalog. The results show a significant number of failures related to numeric value ranges – specifically, several prices are being reported as negative values.' What is a 'contract violation alert' in this context?
A 'contract violation alert' is a proactive notification. It signifies that the data, as it's being processed, isn't adhering to the rules and constraints (the 'contract') established for its structure and content – in this case, numeric value ranges like negative prices are invalid.
18 / 22
Describe in your own words what 'contract-driven testing' implies for a data pipeline. Consider the roles of schemas and validation.
'Contract-driven testing' emphasizes using a clearly defined contract (usually a schema) as the foundation for automated testing. This ensures that each step in the pipeline validates the incoming data against these rules, promoting consistency and immediately flagging any deviations from the expected format or content.
19 / 22
During a standup update, Mark says: 'The data contract tests for the new payment gateway integration are consistently failing due to invalid date formats. The API is returning dates in ISO 8601 format, but our schema expects YYYY-MM-DD.' What's the primary purpose of these data contract tests in this context?
Data contract testing focuses on validation. The tests aren't about *transformation* (that's another layer); they are about ensuring that the data received from the API aligns with what was *agreed upon* – in this case, the expected date format within the schema. This allows for early detection of mismatches before impacting downstream systems.
20 / 22
You are reviewing a PR description for a new data integration service. The description states: 'The data contract tests ensure that all incoming data conforms to the defined schema and validates against key constraints before being processed.' What is the *primary* benefit of this approach?
Data contract testing's core value is early error detection. By validating against a schema *before* processing, it prevents corrupted or inconsistent data from entering production systems – drastically reducing the likelihood of downstream errors. This proactive approach saves significant time and resources compared to reacting to issues after deployment.
21 / 22
Maria is investigating failing data contract tests for a new microservice. The test reports show numerous errors related to the `transaction_amount` field being unexpectedly negative. She asks, 'What does it *really* mean when a contract test fails like this?'
A failed data contract test doesn't inherently mean a problem with the API provider. Instead, it highlights a discrepancy between what the schema *expects* (a positive number) and what is actually being returned from the external source. This often points to an issue in how your code processes or validates the incoming data – a validation failure.
22 / 22
During a Slack discussion about a failing contract test for order processing, Alex says: 'The tests are failing because the API is returning strings instead of integers for the `order_total` field.' What's the most accurate interpretation of this message?
Alex's observation directly points to a data type mismatch. The API is providing a string where the schema expects an integer. This almost certainly indicates a problem with your code's transformation logic – a failure to convert the incoming string into the correct data type *before* it's validated against the contract.
What does the "Data Contract Testing Vocabulary" exercise practise?
Practice vocabulary for testing data contracts: contract violation alerts, Great Expectations, data quality assertions, and dataset contract check language.
How many questions are in this exercise?
This exercise has 22 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 "Data 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.