Contract testing (Pact) in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a Pact consumer test with the correct provider name.

Microservices

const pact = new Pact({ consumer: 'UserService', provider: '[1]' });

Drag options to blanks, or click blank then click option'

APaymentService

BOrderService

CUserService

DInventoryService

Attempts:

3 left

💡 Hint

Common Mistakes

Using the consumer name as the provider name.

Confusing provider and consumer roles.

The provider name must be the service that the consumer depends on. Here, 'OrderService' is the provider for 'UserService'.

2fill in blank

medium

Complete the code to specify the HTTP method in the Pact interaction.

Microservices

pact.addInteraction({ uponReceiving: 'a request for order details', withRequest: { method: '[1]', path: '/orders/123' }, willRespondWith: { status: 200 } });

Drag options to blanks, or click blank then click option'

APUT

BPOST

CGET

DDELETE

Attempts:

3 left

💡 Hint

Common Mistakes

Using POST instead of GET for data retrieval.

Confusing HTTP methods for different operations.

The HTTP method for retrieving data is GET, which matches the request for order details.

3fill in blank

hard

Fix the error in the Pact interaction to correctly specify the expected response status code.

Microservices

pact.addInteraction({ uponReceiving: 'a request for payment status', withRequest: { method: 'GET', path: '/payments/456' }, willRespondWith: { status: [1] } });

Drag options to blanks, or click blank then click option'

A200

B500

C404

D201

Attempts:

3 left

💡 Hint

Common Mistakes

Using 201 which means resource created, not appropriate here.

Using error codes like 404 or 500 for successful responses.

The expected response for a successful GET request is status code 200 (OK).

4fill in blank

hard

Fill both blanks to define the expected JSON response body with correct keys and values.

Microservices

willRespondWith: { status: 200, body: { orderId: [1], status: '[2]' } }

Drag options to blanks, or click blank then click option'

A123

Bconfirmed

Cpending

D456

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string for orderId instead of a number.

Choosing a status that does not match the expected order state.

The orderId should be a number like 123, and the status string should be 'confirmed' to indicate the order state.

5fill in blank

hard

Fill all three blanks to create a Pact test that verifies the provider and writes the pact file.

Microservices

pact.setup().then(() => pact.verify()).then(() => pact.[1]()).then(() => pact.[2]()).catch(e => console.error(e));

// After tests
pact.[3]();

Drag options to blanks, or click blank then click option'

AwritePact

Bfinalize

Ccleanup

DpublishPact

Attempts:

3 left

💡 Hint

Common Mistakes

Calling publishPact() instead of writePact() or finalize().

Not cleaning up resources after tests.

After verification, the pact file is written with writePact(), finalized with finalize(), and resources cleaned up with cleanup().

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