Contract testing basics in Testing Fundamentals - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of contract testing?

Imagine two teams working on different parts of a software system. One team builds a service (provider), and the other builds a client (consumer) that uses that service. What is the main goal of contract testing between these two teams?

A To ensure the provider service has no security vulnerabilities.

B To test the entire system end-to-end including all external dependencies.

C To verify that the provider and consumer agree on the data format and interaction rules.

D To check the user interface responsiveness under load.

💡 Hint

Think about what needs to be agreed upon between two separate parts that communicate.

Contract testing focuses on verifying that the provider and consumer agree on the contract, which defines the data format and interaction rules. This prevents integration issues without testing the entire system.

❓ Predict Output

intermediate

What is the output of this contract test result?

Given this simplified contract test result output, what does it indicate?

Testing Fundamentals

Contract Test Result:
Consumer: OrderApp
Provider: PaymentService
Test: PaymentService accepts order payment request
Result: FAIL
Error: Expected field 'amount' to be a number but got string

A The consumer sent a wrong request format, but the provider responded correctly.

B The provider returned a string instead of a number for 'amount', causing the test to fail.

C The test passed successfully with no errors.

D The provider service is down and did not respond.

💡 Hint

Look at the error message carefully about the 'amount' field type.

The test failed because the provider returned a string for the 'amount' field, but the contract expects a number. This mismatch causes the contract test to fail.

❓ assertion

advanced

Which assertion correctly verifies a contract response field type?

You want to write an assertion in your contract test to check that the provider's response field status is a string with value 'success'. Which assertion is correct?

A assert response['status'] == 'success' and isinstance(response['status'], str)

B assert response.status == 'success' or isinstance(response.status, str)

C assert response['status'] = 'success' and type(response['status']) == 'string'

D assert response['status'] == 'success' and type(response['status']) == str

💡 Hint

Remember Python syntax for assertions and type checking.

Option A correctly uses '==' for comparison and 'type(...) == str' to check the type. Option A is redundant but valid; however, D is more concise and correct. Option A uses 'or' which is incorrect logic. Option A uses '=' which is assignment, causing syntax error, and compares type to string literal 'string' which is invalid.

🔧 Debug

advanced

Why does this contract test fail with a KeyError?

Review this contract test snippet and identify why it raises a KeyError:

Testing Fundamentals

response = provider.get_order(123)
assert response['orderId'] == 123
assert response['total'] > 0
assert response['status'] == 'confirmed'

A The 'total' field is a string, so comparison with 0 causes TypeError.

B The 'orderId' key is misspelled in the assertion.

C The provider.get_order method returns None, so indexing fails.

D The response dictionary does not contain the key 'status', causing KeyError.

💡 Hint

Check which keys are accessed and whether they exist in the response.

The KeyError occurs because the response dictionary lacks the 'status' key. Accessing a missing key with [] raises KeyError in Python.

❓ framework

expert

Which contract testing framework supports consumer-driven contracts with automatic verification?

You want to implement consumer-driven contract testing where the consumer defines the contract and the provider verifies it automatically during CI. Which framework is best suited for this?

A Pact

B Selenium

C JUnit

D Postman

💡 Hint

Look for a framework specialized in contract testing between services.

Pact is a popular framework for consumer-driven contract testing. It allows consumers to define contracts and providers to verify them automatically. Selenium is for UI testing, JUnit is a unit testing framework, and Postman is for API testing but not specialized for contract testing.

Practice

1. What is the main purpose of contract testing in software development?

easy

A. To ensure two systems agree on the format and data of their communication

B. To test the user interface for visual bugs

C. To check the performance speed of an application

D. To verify database schema changes

Solution

1. Step 1: Understand contract testing definition

   Contract testing focuses on the agreement between two systems on how they communicate, including request and response formats.

2. Step 2: Compare options with contract testing purpose

   Only To ensure two systems agree on the format and data of their communication describes this agreement on communication format and data, which is the core of contract testing.

3. Final Answer:

   To ensure two systems agree on the format and data of their communication -> Option A

4. Quick Check:

   Contract testing = communication agreement [OK]

Hint: Contract testing checks communication agreements between systems [OK]

Common Mistakes:

• Confusing contract testing with UI testing
• Thinking contract testing measures performance
• Assuming contract testing checks database structure

2. Which of the following is the correct way to describe a contract in contract testing?

easy

A. A set of UI elements and their styles

B. A list of database tables and columns

C. A defined request and expected response between services

D. A performance benchmark for API calls

Solution

1. Step 1: Identify what a contract defines

   A contract in contract testing defines the request sent and the expected response received between two services.

2. Step 2: Match options to contract definition

   A defined request and expected response between services correctly describes this request-response definition, while others describe unrelated concepts.

3. Final Answer:

   A defined request and expected response between services -> Option C

4. Quick Check:

   Contract = request + expected response [OK]

Hint: Contracts define requests and expected responses [OK]

Common Mistakes:

• Mixing contracts with UI or database details
• Thinking contracts are about performance
• Confusing contracts with test cases

3. Given a contract test that expects a JSON response with a field status equal to "success", what will happen if the actual response is {"status": "fail"}?

medium

A. The test will pass because the response is JSON

B. The test will fail because the status value does not match

C. The test will pass because the field status exists

D. The test will fail due to a syntax error in the response

Solution

1. Step 1: Understand the contract expectation

   The contract expects the status field to have the value "success" exactly.

2. Step 2: Compare actual response to expected

   The actual response has "status": "fail", which does not match the expected value, causing the test to fail.

3. Final Answer:

   The test will fail because the status value does not match -> Option B

4. Quick Check:

   Expected value mismatch = test fail [OK]

Hint: Exact value mismatch causes contract test failure [OK]

Common Mistakes:

• Assuming presence of field is enough to pass
• Ignoring value differences in contract tests
• Confusing syntax errors with value mismatches

4. You wrote a contract test but it always passes even when the provider sends incorrect data. What is the most likely mistake?

medium

A. The contract test has syntax errors and does not run

B. The contract test is missing the request URL

C. The contract test is running on the wrong environment

D. The contract test is not validating the response content properly

Solution

1. Step 1: Analyze why test passes despite incorrect data

   If the test passes even with wrong data, it likely means the test is not checking the response content correctly.

2. Step 2: Evaluate other options

   Missing URL or wrong environment would cause errors or failures, and syntax errors prevent running, so these are less likely.

3. Final Answer:

   The contract test is not validating the response content properly -> Option D

4. Quick Check:

   Incorrect validation = false pass [OK]

Hint: Check if test actually validates response content [OK]

Common Mistakes:

• Ignoring validation logic in tests
• Assuming environment issues cause false passes
• Confusing syntax errors with test logic errors

5. You have two microservices: Service A (consumer) and Service B (provider). Service A expects Service B to return a JSON with a userId as a number and active as a boolean. Which contract test scenario best ensures compatibility?

hard

A. Test that Service B returns {"userId": 123, "active": true} and reject if types differ

B. Test that Service B returns any JSON object with keys userId and active regardless of types

C. Test that Service B returns a string containing userId and active anywhere

D. Test that Service B returns a JSON with userId as string and active as number

Solution

1. Step 1: Identify expected data types in contract

   Service A expects userId as a number and active as a boolean, so the contract must enforce these types.

2. Step 2: Evaluate options for strictness and correctness

   Test that Service B returns {"userId": 123, "active": true} and reject if types differ tests exact types and values, ensuring compatibility. Options A, B, and C ignore or mismatch types, risking integration errors.

3. Final Answer:

   Test that Service B returns {"userId": 123, "active": true} and reject if types differ -> Option A

4. Quick Check:

   Strict type check = compatibility ensured [OK]

Hint: Contract tests must check exact data types and values [OK]

Common Mistakes:

• Ignoring data types in contract tests
• Accepting any JSON structure without validation
• Confusing string and number types in contracts