Tutorial: Improving your integration testing efforts with consumer-driven contract testing

Monoliths are dead. Or, at the very least, they are quickly going the way of the dinosaur. Modern applications are built out of loosely coupled, independent components (i.e., microservices) that communicate with one another through standardized protocols and message formats (HTTP, REST, …).

While this is a blessing for software development, as it enables quick deployments and parallel development, among other things, it does pose some additional challenges in terms of integration and E2E testing. At all times, you want to be informed about whether all of the components and services that make up your application can still communicate with one another. Setting up large scale test environments for all of these components, either using ‘the real thing’ or stubs, can quickly become a Herculean task.

Contract testing is an approach that is meant to address these challenges of large-scale integration and E2E testing in distributed environments. It is not a new technique, in fact, it has been around for several years now, but unfortunately there is a lack of good introductions, examples and use cases that clearly show the added value of contract testing, and how it can help speed up integration testing.

This workshop is meant to address that. Using a (fictional, but based on real experience) use case, the participants will go through the following steps:

* The challenges of integration testing in distributed environments
If you’re working on a monolith and all components of a system are developed in the same team or department, integration testing is relatively easy. Once the monolith is deployed, you can start testing. However, if a system consists of small, independent components, teams quickly start to struggle. Are all components available for testing? Is development ready? Is all required test data in place? How about versioning? The higher the level of distribution, the more difficult this gets.

In this step, I’ll introduce the players in the arena: two API consumers from different teams that would like to communicate with a single API provider, developed in a different department.

* Introducing contract testing
As a potential solution to the integration testing challenges, I’ll introduce the concept of contract testing and how it differs from (and augments) traditional functional and integration testing.

In this step, I’ll introduce Pact, and together we will go through a complete contract testing cycle. This helps participants grasp what contract testing really is about and how it addresses the issues we talked about earlier.

* Changes over time
As systems evolve, new changes will be implemented both on the consumer and on the provider side. But what effect does that have on the ability for consumers and providers to work together?

In this step, I will introduce a couple of changes on the consumer side that lead to updated contracts. The participants will see what effect this has on the contracts and the contract testing process (i.e., how this breaks the testing pipeline). In this way, they will experience first-hand the types of potential integration issues that contract testing is meant to detect and signal.

* A new kid on the block
As participants will have seen by now, contract testing can be a great addition to an integration testing strategy. However, introducing contract testing means adding new tools and new ways of working, which is a pretty big first step for a lot of teams. The concept of bi-directional contracts (https://pactflow.io/blog/bi-directional-contracts/) is meant to address that challenge.

In this step, I’ll introduce a second API provider and show how they can be added to the existing contract testing setup using their existing contract (API) specifications, without the need for implementing full-blown ‘traditional’ contract testing.

At the end of this workshop, participants will have a good overview of the concept of contract testing, they will have gained hands-on experience with contract testing and they will have seen what it takes to introduce contract testing in their software development lifecycle. All code from the workshop will be available through GitHub, giving the participants an example they can replay from the comfort of their own home or office.

Presentation: Mutation testing for fun and profit – Improving the quality of your unit tests

Test automation plays an important role in safeguarding the quality of your code and your software. But who tests your tests? What do you know about the quality of your tests?

In this talk, you’ll see different ways in which your tests can deceive you and give you a false sense of security. You’ll also learn about mutation testing, a technique that helps you get insight into the quality of your tests. You’ll see how mutation testing works in practice by means of a live demo on a Java code base.