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.
In previous parts, I talked about the contents of each approaches contracts. The approaches are different, which results in different types of contracts.
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.
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.
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.
When testing on an end-to-end environment…
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…
TL;DR: See Conclusion.
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.
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
Testconsultant @ Bartosz