Someone messaged me on LinkedIn asking if I’d heard of Contract testing. I don’t think I’ve heard this term before, does anyone else know what this is?
My initial guess is that it is a kind of User Acceptance test where the application is tested against the requirements stated in a contract. This is a complete guess though.
They didn’t mean going into contracting to do testing?
As that’s where my mind would immediately go to.
That was my first thought, too. Were they asking about you signing a contract to do testing?
I agree with the other replies. Since the source was LinkedIn, it was possibly ‘lost in translation’ by a recruiter.
Ok - Disclaimer: Learning about it, so might be off the mark, but they do say that if you can explain it, then you “understand” it.
Basically contract testing is a way of testing your services between you and another service.
e.g One of the services will be a provider (they will send responses based on the data that is sent) while the other service is going to be the consumer of said responses/events.
What contract testing aims to do is improve the feedback of when changed features break other services that are dependant on each other.
You write tests (or contracts) that state something along the lines of
“If I send A, then I expect B”.
If B is sent back, then the contract is fulfilled and the tests pass
If C is sent back, then something is wrong and the tests fail.
The other services within your test framework will be mocked out.
Pros of this approach is that you have to talk to other people to figure out what contract tests are valuable.
Basically, it’s a way of saying. These are my T&Cs for us to work correctly.
I know this is a simple way of explaining it, but like I said, still learning so some deeper explanation is probably needed.
Check out PACT - https://docs.pact.io
Cool. Thanks for the info, I’ve learned something new today, my work here is done. 
@decosta That is my contextual understanding of contract testing as well.
I’ve typically used it for both internal in my team and external communication.
When the api dev team (typically backend teams) deploys / builds new instances of infrastructure of their API, I’ve setup contract tests as a post deploy test that ensure those API instances are responding in the way the api devs have communicated to its consumers (typically frontend teams)
In the company I work for we’ve tried pact.io and then moved to apikli, which is also a nice alternative. https://github.com/apickli/apickli. It has a cucumber layer at the top which allows you to write the tests using Gherkin syntax.
Have used contract testing in many forms in the past. As explained above, it is a way to ensure that 2-services can operate with each other whilst also reducing the risk of breaking the ‘contract’ with other services when a change is made. The last thing you need an API service to do is break all other services using it when you change the response.
Have looked recently into PACT, only since it is better than a documented agreement. Will look at apikli now, it might be easier since we are using Specflow / cucumber for our acceptance testing and unit tests - Thanks Jose!
Yup, contract testing is a type of testing in its own right, rather than referring to the type of contracts we might be used to talking about in a business context. @decosta has already done a good job of explaining the high-level goal / usage.
If you want to learn more about contract testing, @steveburton4 has also written a series on the topic (which I dug through my email trash to find for you ;P) https://www.testersfindaway.com/2019/01/21/testing-your-contracts-1-5/
It gets quite technical for me at points, so there’s definitely more learning for me before I fully understand everything, but it seems like Steve might be able to help with any specific questions you might have.
Thanks guys, loads of really useful information.
Thanks @cassandrahl. Just seen this but absolutely happy to help with any specific questions if you have any @lgibbs. Can ask me on here or feel free to DM me on twitter (testersfindaway).
A contract describes how components communicate and interact with each other, both message formats between components (syntax) as well as behavioral expectations of components (semantics). You use contract testing to verify that contracts between components are honored; this gives you confidence that the components are able to work together. When you use test-specific dependent components (such as test doubles), you can also use contract testing to make sure that they honor the latest or any specific version of the contract. Here are several ways of testing or managing contracts between components: (…)
