Intro to PACT for .NET Core: Events based systems

This is a continuation of the PACT for .NET series where I am going to cover the usage of PACT in event-based systems.

This article assumes the readers will have a basic understanding of event-based systems and frameworks. In case not, a good place to start can be RabbitMQ Tutorials.

I will be using the same repo setup that I have used to demonstrate usage in API-based systems. I have covered the setup in detail in a previous blog in this series:

Contract testing for APIs: Intro to PACT for .NET Core

Intro to PACT for .NET Core: API contract testing

devcodex.in

For illustration purposes, we can imagine a scenario where the Result service (Consumer) wants to get informed whenever a student is created.

Now since both Result and Student are separate services, below is the infrastructure that has been implemented in order to make that work.

I have incorporated the RabbitMQ library as a messaging service in both the APIs.

Whenever a new student is created using the Student service’s (Provider) POST API, we are publishing an event called StudentCreatedEvent.

The event structure includes details such as:

Now the above event can be listened to by any service interested in that event. In this scenario, that service is the Result service.

There is a listener defined in the Result service which may perform any operation based on the information received in the StudentCreatedEvent.

For example, it may store student details in the Result service to avoid direct dependency on the Student service while preparing results.

The first part of contract testing involves defining the expected event structure on the consumer side, which results in generating a PACT JSON contract file.

Once the contract is defined, a PACT JSON contract file is generated, which looks something like this:

Now that this contract file has been created, we need to write tests on the provider side to ensure that it adheres to the contract.

Now that this setup is ready, we can quickly do a build and test:

Alternatively, you can run individual tests as well.

To test a failure case, we can make some changes in our provider. For example, renaming the LastName field to LName and rerunning the tests.

When we run the tests, we can see the results:

As we see in the results above, the error message suggests that the LastName field is missing on the provider side.

By implementing contract testing with PACT for event-based systems, we ensure reliable integrations between services.

This methodology helps detect issues early, ensuring both consumer and provider remain in sync.