When contracts become expensive mocks…
Marit van Dijk
Short talk - in English
When I joined my current team, I was excited to see they were very test-minded and had a lot of test automation in place. They were using some tools I was already familiar with, and some I was not.
One of the latter was Spring Cloud Contract Testing. In a microservices landscape like we have at bol.com, it’s important to make sure all of the different services managed by different teams work well together. A test environment is not always available or reliable, and when testing your service in isolation, how do you know your mocks are valid? This is where contract testing comes in.
However, I quickly noticed that running the contract tests was taking up a lot of time. We had 206 contracts for 15 other services. And what’s worse, the other services were not even using the contracts to make sure they’re not breaking their API! The “contracts” were, in fact, just expensive mocks…
So we set out to replace these “expensive” mocks with faster tests, while increasing coverage and decreasing our build time! In this talk I will tell you how we went about it. This might help you think about your test strategy, and what to test where and how.
• What is Contract Testing? When should you use it? (And when should you not?)
• How do you determine what to test where? What is the value of different types of tests?
• How can you replace slow tests with faster tests, to get the right feedback at the right time?