Here’s a detailed overview of Consumer-Driven Contract Testing (CDCT) and Consumer-Side Contract

Testing, explained simply and technically, along with friendly FTGO examples for each.

Consumer-Driven Contract Testing (CDCT)

Simple Explanation: Consumer-Driven Contract Testing is a way for a service (the consumer) to
define how it expects another service (the provider) to behave. This testing approach focuses on
ensuring that the provider’s API meets the expectations set by the consumer, which helps prevent
any changes from breaking the consumer's functionality.

Imagine you’re ordering food from the FTGO application. The Order Service (consumer) wants to
make sure that the Menu Service (provider) provides the correct menu items. Before the Order
Service uses the Menu Service, it writes down its expectations about what the Menu Service should
return. These expectations form a contract that the Menu Service needs to fulfill.

Technical Explanation: In CDCT, the consumer writes tests that describe the expected behavior of the
provider’s API. These tests typically include details about the requests made to the provider and the
expected responses.

The provider then verifies its implementation against these tests. If any changes occur in the
provider’s API, the consumer tests will ensure that the new implementation still meets the defined
contract. This approach fosters collaboration between teams, as it encourages communication about
how the services should interact.

FTGO Example: In FTGO, consider the Order Service that fetches menu items from the Menu
Service. The Order Service specifies that when it sends a request to fetch the menu, it expects a
specific format in the response, including the item name and price.

1. The Order Service team creates tests that define the expected response from the Menu
Service:

o Expected status code: 200 (OK)

o Expected response body format: List of menu items with names and prices.

2. The Menu Service team runs the tests from the Order Service against its implementation to
verify that the service behaves as expected.

By ensuring that the Menu Service meets these expectations, the Order Service can confidently
interact with it, knowing that any changes will not break its functionality.

Consumer-Side Contract Testing

Simple Explanation: Consumer-Side Contract Testing focuses on the consumer's perspective, where
the consumer tests its own expectations against a mock version of the provider service. This means
that instead of relying on the actual provider service, the consumer simulates the provider's behavior
to ensure that it can function correctly based on the assumed contract.

Think of it like a rehearsal before the big performance. The Order Service (consumer) practices how
to handle menu data by pretending to get responses from the Menu Service (provider) without
actually calling it. This way, it can ensure that it correctly processes the data it expects.

Technical Explanation: In this testing pattern, the consumer creates stubs or mocks of the provider
service based on the contracts it has defined. This allows the consumer to simulate how the provider
will behave without needing the actual provider service to be running. The consumer then runs its
tests against these mocks to ensure its functionality aligns with the expected contract.

Using tools like Pact or other mocking frameworks, the consumer can automate the process of
verifying that its implementation correctly adheres to the contract, ensuring that any assumptions
made about the provider's behavior are validated.

FTGO Example: Continuing with the FTGO application, the Order Service may want to ensure that it
can handle menu data correctly. Instead of relying on the actual Menu Service, it uses a mock service
that simulates the responses it expects.

1. The Order Service creates a mock version of the Menu Service that returns predefined menu
items.

2. The Order Service runs tests to check how well it processes the menu items, ensuring it
correctly calculates totals or handles items that are out of stock.

3. If the mock responses change, the Order Service can adjust its logic accordingly before the
actual Menu Service is modified.

Summary

Both Consumer-Driven Contract Testing and Consumer-Side Contract Testing help ensure that
services in a microservices architecture, like FTGO, can communicate effectively and maintain
compatibility. By defining expectations and testing against them, teams can work more
independently while still ensuring that their services will interact smoothly.

 CDCT emphasizes the agreement between consumer and provider, focusing on shared
contracts.

 Consumer-Side Contract Testing allows the consumer to validate its functionality against
simulated provider behavior, ensuring robustness and reliability before the actual services
are integrated.

Stubs

Definition: A stub is a simplified version of an object or service that provides predefined responses to
method calls. It doesn’t contain any complex logic or behavior—it's just there to supply the data
needed for testing.

Example: Imagine you’re testing a Booking Service for a hotel. This service needs to retrieve
available rooms from a Room Service. Instead of querying an actual database for available rooms,
you can create a stub for the Room Service that always returns a fixed list of rooms, regardless of the
actual room availability.

Scenario:

 Stub: The stub for Room Service always responds with: "Room 101: Available, Room 102:
Available."

 Usage: When the Booking Service calls the Room Service to check availability, it receives the
stubbed response. This allows you to test how the Booking Service handles room availability
without needing to connect to a real database.

Mocks
Definition: A mock is a more advanced version of a test double that not only simulates the behavior
of a real object but also allows you to verify that certain interactions happened as expected. Mocks
can track how many times methods were called and what arguments were used.

Example: Let’s consider the same Booking Service for a hotel. This service may need to send a
confirmation email through a Notification Service after a booking is made. Instead of using the
actual notification system, you can create a mock for the Notification Service.

Scenario:

 Mock: The mock for Notification Service will simulate sending an email and keep track of
whether it was called.

 Usage: After making a booking, the Booking Service calls the mock Notification Service to
send a confirmation email. The test checks that the Notification Service’s send method was
called exactly once with the correct booking details.

Summary

 Stubs: Think of them as basic stand-ins that provide fixed responses. They’re great for when
you need specific data to test your service without dealing with real data sources.

 Mocks: These are more interactive and allow you to verify behaviors. They help ensure that
your service is not just getting the right data but also behaving as expected by calling other
services correctly.

In the context of our hotel example, stubs help you test what happens when rooms are available,
while mocks help you verify that the system sends confirmation emails after a booking.