Two rams locking horns
Two rams locking horns
Photo by jean wimmerlin on Unsplash

In part 3 and part 4, I’ve explained how the two approaches to contract-based testing work. I’ve talked about the provider-driven approach in part 3 and the consumer-driven approach in part 4.

In this part, I want to compare the two approaches to each other. While doing this, I’ll provide some more detail on the approaches.

Contracts

In previous parts, I talked about the contents of each approaches contracts. The approaches are different, which results in different types of contracts.

Provider-driven


Image for post
Image for post
Photo by Annie Spratt on Unsplash

In part 3, I’ve started explaining how contract-based testing works. To that end, I’ve talked about the provider-driven approach.

In this part, I want to add to that by talking about the consumer-driven approach. There is more to unpack here than in the provider-driven approach. Because of this, the comparison between the two approaches will have to wait until part 5.

Consumer-driven contract-based testing


Developer staring out the window
Developer staring out the window
Photo by Christina @ wocintechchat.com on Unsplash

In part 1, I’ve talked about what contract-based testing is. In part 2, I continued with why we should prefer contract-based testing over end-to-end testing.

In this part, I want to start with how contract-based testing works. While doing so, I’ll also go into the details of the provider-driven approach. Sadly, the consumer-driven approach will have to wait until part 4.


Developer looking at his laptop with hand in his hair
Developer looking at his laptop with hand in his hair
Photo by Tim Gouw from Pexels

In part 1, I’ve talked about the basics of contract-based testing. I haven’t talked about the specifics of contract-based testing yet, I will do so in part 3.

Before I dive deep into the details of contract-based testing I want to take a small step back to talk about end-to-end testing. Both contract-based tests and end-to-end tests are ways to test full applications. These approaches have a lot of overlap. In this article, I want to talk about some issues of end-to-end tests and why contract-based tests are a better fit for most situations.

End-to-end testing

When testing on an end-to-end environment…


Person holding a clipboard with some papers.
Person holding a clipboard with some papers.
Photo by cottonbro from Pexels

Modern software architecture promotes building tightly scoped, reusable applications. Because of this, big organisations have hundreds of applications working together at any given time. These applications talk to each other via their interfaces. These complex networks of applications can cause hard-to-trace bugs which are often difficult to test.

Contract-based testing is a fundamental way to approach testing the interfaces between applications. It gives you the confidence that two applications can talk to each other with no need for an end-to-end environment.

In this series of articles, I will talk about what contract-based testing is, why you should use it, and…


Image for post
Image for post
Image by xresch from Pixabay

TL;DR: See Conclusion.

Prefer reading Dutch?

I’ve been a software tester for a little over a year and a half now. In that period the number of times I had to test something manually can be counted on one hand. Yet every time I Google something related to testing I come across these references that many people are still testing manually. I also hear from Colleagues that they are testing manually regularly.

That baffles me. To me, testing something manually feels like time wasted, and not the good Netflix kind. …


I could not find a good human-readable resource about Problem. Therefore I’m writing it myself.

What is Problem JSON

Problem is a standardized way of describing any kind of error thrown by an API. A Problem can be described in JSON or XML, but we’re only going to talk about the JSON variant in this article.

The purpose of Problem is so that “API [consumers] can be informed of both the high-level error class (using the status code) and the finer-grained details of the problem”.

For those of you who don’t like reading, here is an example Problem JSON response:

HTTP/1.1 401 Unauthorized Content-Type…

Sander van Beek

Testconsultant @ Bartosz

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store