Why Contract testing? Benefits, solutions. PACT vs Spring Cloud Contract vs custom highly scalable solution

Definition

Contract testing is a technique for testing systems integration by checking each application in isolation to ensure that contracts and interfaces comply with the agreement that each side is aligned and agreed upon.

Explanation

A mock integration point allows verification that a component can behave as expected. It is possible to verify its absence without relying on that component.

Given a large and complex application, it may be necessary to have an integration point that is trusted by multiple applications.

With a trusted integration point, the behaviors of the integration point are validated by all of the applications relying on it, which prevents accidental or malicious changes from affecting the overall system.

In this way, it is possible to build a system where every component in the system performs the same specific task, and the system is safe from accidental or malicious changes to any of the components.

Why should I choose contract testing? What are the points of choosing it?

This technique is very good for:

• detecting any irregularities in a consumer workflow and spot those changes in earlier stages
• detecting any service configuration defects that might affect the communication between applications
• keeping the connections safe even when the producer changes any service configuration that will provide guarantees to consumers of the data
• producers can carry out their tasks without breaking down the consumer’s workflow and which will be very helpful also in regression tests
• the consumer has the freedom to define their requirements and consume only what it needs
• fights sudden API communication failure due to local or mock implementation which is also more stable, faster, and reliable during the testing phase of the application
• fast issue detecting and fixing time

When you should not use contract testing?

It is always good to know 2 sides of the coin before making any decisions.

Let’s look at the main points when contract testing is not suitable.

• contract tests won’t replace Unit / Functional (component) tests
• contract tests are not meant to substitute for any other tests
• if you have no or low communication between teams where you want to set up contract tests because it’ll lead to a stale contract which you shouldn’t trust or rely on
• with a phrase “let’s try and use it because it’s another layer of test coverage” or “it’s a fancy and new technique” or similar. This won’t bring you any value for just having them in your test flows
• before making any decisions it’s always good to weigh the business value, ETA (estimated time arrival) for the implementation and thinks of MPV (minimum viable product) that you can provide and present. Good to mention, that integrating any new features or tools requires workshops to onboard teams and users

Where do contract tests reside based on the testing pyramid?

Testing pyramid

To zoom in a little more, let’s take a look at the table below

What tools can I use? What options do I have?

There are not many tools that you can choose from for implementing contract testing that is battle proof and production-ready.

1. Pact — https://docs.pact.io
2. Spring Cloud Contracts — https://spring.io/projects/spring-cloud-contract

Which tool should I choose? Points to consider when choosing the right tool for your project

A quick summary that illustrates what each tool can provide for making a right decision

What approaches or flows does each tool uses by default? How do they differ from each other?

Let’s take a look at what producer-driven contract testing looks like

Producer-driven approach

In a producer-driven approach, the producer will create and generate contracts and pass them to consumers.

Right now let’s take a closer look at how the Spring Cloud Contract tool works and what it does behind the scene

Spring Cloud Contract workflow

Next, let’s look at the consumer-driven contract testing flow

Consumer-driven approach

The image below illustrates how Pact works

Pact workflow

What is the process of creating a new contract? Workflow

Add new contract

1. Add contract to contract repo
2. Contract review
3. Implement test on the consumer side
4. Implement test on the producer side
5. Merge contract
6. Merge consumer test
7. Merge producer test

Update existing contract

1. Update contract in contract repo
2. Review the contract
3. Apply changes on each consumer’s side
4. Apply changes on each producer’s side
5. Merge contract changes
6. Merge consumer changes
7. Merge producer changes

At what stage contract tests should be executed? Integration into the development pipeline

1. Build phase

1.1 build code

1.2. generate contracts

2. Test phase: perform in parallel

2.1 unit tests

2.2. integration tests

2.3. contract tests — it’s good to consider a backup plan (safe failure) if you need a quick production deployment during an incident

2.4. other automated tests

3. Deploy to production

Conclusion

In this article, I explained what contract testing is, what are the pros and cons of it, and showed the points to make the right decision.

Next steps

In the next article, I’ll show how you can build a highly scalable solution with GitHub or GitLab pipelines.

Custom highly scalable solution for contract testing