Contract testing (Pact) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the Purpose of Contract Testing with Pact

Which of the following best describes the primary purpose of using Pact in microservices?

A To monitor live traffic between microservices in production environments.

B To perform load testing on microservices to check their performance under stress.

C To automate UI testing of microservices' front-end interfaces.

D To verify that the interactions between a service consumer and provider meet a shared contract without deploying the services.

💡 Hint

Think about what contract testing ensures between two services before they communicate.

Pact is used to verify that the consumer and provider agree on the API contract, ensuring compatibility without needing to deploy both services together.

❓ Architecture

intermediate

Key Components in a Pact Contract Testing Setup

Which component is responsible for generating the contract file in a Pact testing setup?

A The API gateway generates the contract by intercepting traffic.

B The service provider publishes the contract after running its tests.

C The service consumer generates the contract during its tests.

D A separate contract registry automatically creates contracts from API definitions.

💡 Hint

Consider which side defines the expected interactions first.

The consumer writes tests that define expected requests and responses, generating the Pact contract file used to verify the provider.

❓ scaling

advanced

Scaling Contract Testing in a Large Microservices Environment

In a system with 50 microservices, each with multiple consumers and providers, what is the best approach to manage Pact contract testing efficiently?

A Skip contract testing for less critical services to reduce overhead.

B Centralize all contracts in a shared Pact Broker and automate verification pipelines for each service.

C Each team manually shares contract files via email and runs tests locally before deployment.

D Use a single monolithic contract file for all services to simplify management.

💡 Hint

Think about automation and centralization for large-scale coordination.

A Pact Broker centralizes contracts and automates verification, making it scalable and manageable for many services.

❓ tradeoff

advanced

Tradeoffs of Using Contract Testing vs. End-to-End Testing

Which statement best describes a tradeoff when choosing Pact contract testing over full end-to-end testing?

A Contract testing provides faster feedback and isolates integration issues but may miss UI or infrastructure problems caught by end-to-end tests.

B Contract testing is slower and more expensive than end-to-end testing but provides better UI coverage.

C Contract testing replaces the need for any other testing types, including unit and integration tests.

D Contract testing requires deploying all services together, increasing complexity compared to end-to-end testing.

💡 Hint

Consider what contract testing focuses on versus what end-to-end testing covers.

Contract testing isolates API compatibility issues quickly but does not test full user flows or infrastructure, which end-to-end tests cover.

❓ estimation

expert

Estimating Pact Contract Test Execution Time in CI Pipeline

You have 20 microservices, each with 5 consumers. Each Pact verification test takes 10 seconds. Assuming all tests run sequentially, estimate the total Pact verification time in the CI pipeline.

A 1000 seconds

B 6000 seconds

C 1500 seconds

D 3000 seconds

💡 Hint

Calculate total tests as number of microservices × consumers, then multiply by test time.

Total tests = 20 services × 5 consumers = 100 tests. Each test takes 10 seconds, so total time = 100 × 10 = 1000 seconds.

Practice

1. What is the main purpose of contract testing in microservices using Pact?

easy

A. To check database schema consistency

B. To test the user interface of a microservice

C. To verify that services agree on request and response formats

D. To measure the performance of a microservice

Solution

1. Step 1: Understand contract testing role

   Contract testing ensures that two services agree on how they communicate, specifically the request and response formats.

2. Step 2: Identify Pact's function

   Pact automates contract testing by creating and verifying these agreements between microservices.

3. Final Answer:

   To verify that services agree on request and response formats -> Option C

4. Quick Check:

   Contract testing = Verify service agreements [OK]

Hint: Contract testing checks communication agreements, not UI or performance [OK]

Common Mistakes:

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

2. Which of the following is the correct Pact file format used to define a contract?

easy

A. JSON

B. YAML

C. XML

D. CSV

Solution

1. Step 1: Identify Pact contract format

   Pact contracts are written in JSON format to describe interactions between services.

2. Step 2: Eliminate other formats

   YAML, XML, and CSV are not used by Pact for contract files.

3. Final Answer:

   JSON -> Option A

4. Quick Check:

   Pact contract format = JSON [OK]

Hint: Pact contracts are JSON files describing service interactions [OK]

Common Mistakes:

• Assuming Pact uses YAML or XML
• Confusing data formats with contract formats
• Thinking CSV can describe complex contracts

3. Given the following Pact interaction snippet, what is the expected response status code?

{"request": {"method": "GET", "path": "/users/123"}, "response": {"status": 200, "body": {"id": 123, "name": "Alice"}}}

medium

A. 404

B. 200

C. 500

D. 302

Solution

1. Step 1: Read the response status in the Pact snippet

   The response object shows "status": 200, indicating a successful request.

2. Step 2: Confirm status meaning

   Status 200 means OK, so the expected response code is 200.

3. Final Answer:

   200 -> Option B

4. Quick Check:

   Response status in Pact = 200 [OK]

Hint: Look for "status" field in response to find expected code [OK]

Common Mistakes:

• Confusing request method with response status
• Ignoring the status field in the response
• Choosing common error codes instead of actual status

4. A Pact test fails because the provider service returns an extra field not defined in the contract. What is the best way to fix this?

medium

A. Remove the extra field from the provider service response

B. Ignore the extra field in the provider service

C. Disable contract testing for this interaction

D. Update the contract to include the extra field

Solution

1. Step 1: Understand contract strictness

   Pact expects the provider response to match the contract exactly, including fields.

2. Step 2: Adjust contract or provider

   If the provider adds a new field, the contract must be updated to reflect this change to keep tests valid.

3. Final Answer:

   Update the contract to include the extra field -> Option D

4. Quick Check:

   Provider adds field -> update contract [OK]

Hint: Keep contract and provider response in sync to pass tests [OK]

Common Mistakes:

• Ignoring extra fields without updating contract
• Removing fields from provider causing data loss
• Disabling tests instead of fixing contract

5. You want to implement contract testing with Pact in a microservices system where multiple teams develop services independently. Which approach best ensures smooth integration?

hard

A. Each team publishes their Pact contracts to a shared broker for others to verify

B. Teams test contracts only locally without sharing

C. Use end-to-end tests only, skipping contract tests

D. Manually review API changes without automated tests

Solution

1. Step 1: Identify best practice for contract sharing

   Using a shared Pact broker allows teams to publish and verify contracts centrally, enabling independent development with integration confidence.

2. Step 2: Compare alternatives

   Local-only tests lack visibility; end-to-end tests are slower and less focused; manual reviews are error-prone.

3. Final Answer:

   Each team publishes their Pact contracts to a shared broker for others to verify -> Option A

4. Quick Check:

   Shared Pact broker = smooth integration [OK]

Hint: Use shared Pact broker for contract visibility and verification [OK]

Common Mistakes:

• Skipping contract tests for only end-to-end tests
• Not sharing contracts causing integration surprises
• Relying on manual API reviews