How Consumer-Driven Contract Testing in 2023 Can Change Your Life

We’ve all been there – you’re working on a project that passes unit testing, but when you run integration tests, everything breaks. Or you save integration testing until the very end and struggle to get integration teams on the same page at the same time (due to availability, offshore teams, new project priorities, etc.). Before you know it, integration testing feels like a whole new project.

To make matters more challenging, integration tests can also run for hours before they succeed or fail, and the visibility into why an integration test may have failed is dependent on whether your team has used a real service or a mock service. If you used a real service and that service goes down during testing, you just added more testing cycles to your team’s workload. And if you used a mock service, are you truly testing what the integration looks like? Or are you testing it against inaccurate expectations? And can your project truly be successful?

So, it’s no surprise that traditional testing desperately needs a change. Enter consumer-driven contract testing. Keep reading to learn how CDC testing can help you improve the quality and reliability of your applications, reduce the risk of integration failures, increase your teams’ speed of delivery, and practically change your life in 2023.

What is consumer-driven contract testing?

Consumer-driven contract testing flips the idea of testing on its head a little bit. CDC testing is a technique used to ensure that the interactions between two systems — such as a consumer and a provider — are working as expected. This technique involves the consumer creating a set of tests that define the contracts or expectations for how the consumer (e.g., a user or UI) will interact with the provider (e.g., an API). The provider then checks that it can meet these expectations by running or incorporating the consumer’s tests into its own platform.

In consumer-driven contract testing, the consumer is in control of defining the expected output results and providing the test data which can help to ensure that the provider is meeting the needs of the consumer. This approach can be particularly useful in microservices architectures where multiple independent services are interacting with one another. By using consumer-driven contract testing, you can catch issues before they affect the end users of your system, helping to improve the reliability and stability of your services.

What else can you expect from consumer-driven contract testing?

• Better documentation for test cases (when “given-that-then” is implicitly defined)
• Since it’s created by a user, you reach a deeper level of testing
• You uncover things earlier that may not have been identified in the specs (for instance, date formats); since the user provides the data to the implementer, you’re already aligned

Why is it important?

CDC testing is vital to organizations looking to reduce the risk of errors and defects in their work. By verifying the contracts between the consumers and the providers of services, CDC testing helps to catch issues early in the development cycle before they become more costly and more challenging to fix. It incorporates true accountability and avoids the “he said/she said” blame game.

Some other benefits of CDC testing include: 

• Reducing the need for manual testing (by automating the verification of contracts)
• Giving teams time and space to focus on more valuable tasks
• Increasing speed as CDC testing can be incorporated into your unit testing on both sides; also increases speed in terms of iteration because as you naturally work on your unit test, you can iterate more frequently
• Providing deeper testing earlier in the software development life cycle
• Challenging service users to brainstorm how they can use the service earlier, allowing for parallel development for UI before the service is ready
• Serving as a foundation for service mocks that are used by your teams, helping with their overall testing strategy
• Benefitting multiple teams, while traditional testing is often confined and benefits one team (which often translates into other teams only benefitting from results, not the tests themselves)

Putting it into practice

Implementing consumer-driven contract testing in your organization can be a challenging process, but the benefits are well worth the effort. We recently worked on a project that illustrates what consumer-driven contract testing looks like when put into practice.

In this project, we leveraged Kafka, an event-driven message queue that allows systems to operate together asynchronously. In our case, we had a very loosely defined object model with simple differences like which fields were required and date formatting standards.

Benefits

Since we operated in this model, our consumer-driven contract testing found that our consumer was expecting fields A and B to always be populated, but sometimes, those fields (one or both) didn’t exist. This allowed our team to identify a flaw in our upstream design much earlier on and resolve it earlier too.

Pitfalls

The engagement model feels slower compared to traditional methods of testing. Working with multiple spread-out teams means they advance at their own pace. Since requirements are defined upfront, this also means they can charge ahead (almost in an “ignorance is bliss” mentality). You may think you’re all driving towards the same finish line but remember – if there’s no shared conductor, your destinations can feel like they’re worlds apart.

When all those spread-out teams finally align and come together, everyone’s minor assumptions have deviated, leading to team degradation. Now you’re debating topics that should have initially just been questions, and since they were identified so late in the process, your team has to go back and fix them. You also face challenges of those decisions becoming foundational for other decisions and the unwinding effect can be expensive and frustrating.

In CDC testing, the process feels slower since you’re exploring those same questions earlier on, but you catch up a lot faster than you would. If you buy into the notion that questions forcing decisions earlier on will always see that pay off, you’re a great candidate to start CDC testing today!

Misconceptions about CDC testing

A misconception about CDC testing is that you’re pushing more work onto someone else’s plate. The reality is that CDC testing is better for everybody and is ripe with benefits in the long run. Additionally, CDC isn’t an excuse not to test your service as the provider of it. This is a bad misconception that someone may use to do less or evade work.

CDC testing also challenges traditional thinking because you’re closer to test-driven development, which can be a painful process without good structure and practice. It goes against tradition because it encourages you to think about the use of a service before it even exists as opposed to what you want the service to become. You’re flipping the mentality altogether. Don’t think about what the service can do, think about what you need from it in a particular use case.

This mindset shift is incredibly beneficial. If you’re thinking about a service from a use case perspective, you’re inching closer to a true user experience. Often, you’ll find that services built without a user experience in mind, even if the user is another system, will face adoption challenges. In contrast, services created from a use case environment can be consumed by a broader audience (for instance, low-code and no-code audiences) and consumers, expanding the overall engagement. You’ve just shifted from a functional mindset to a user-need mindset.

Using consumer-written tests

If you align on standard approaches for testing technologies, you can leverage what was once developed as a consumer-driven contract test as a fundamental base test of your service. This is the ultimate goal of CDC testing: to write one set of tests and mocks that are leveraged by both sides of an integration during unit testing. A true single source eliminates any communication gaps, but admittedly does require much deeper organizational alignment.

How can you get started with CDC testing?

It starts internally. If getting buy-in from your teams is a roadblock, you can start this process individually to build a case for it by putting yourself in the position of the consumer. Instead of thinking about your application as a unit testable solution, think of the project and the way it would be used to build something. Then, fill in the “given-that-then” test results yourself, and use those results to drive that initiative forward.

It’s a way to leverage your efforts as the producer of the service to help teams to get off the ground with CDC testing, which you’ll immediately see the benefits of and get buy-in. Move the needle with CDC testing and witness a stark transformation in the way you build and maintain your software, making your organization more competitive and successful in 2023 and beyond.

---

Indellient is a Software Development Company that specializes in Data Analytics, Cloud Services, and DevOps Services.

If your organization needs help getting started (or tried and is now running into roadblocks), contact our team to see how we can help you attain cloud transformation.

---