Spring Cloud Contract in a polyglot world

<div class="paragraph"> <p>This article contains a short reminder of what Contract Testing is, how Spring Cloud Contract implements it, and how Spring Cloud Contract can be used in a polyglot world.</p> </div><h1 id="what-is-contract-testing" class="sect0"><a class="anchor" href="#what-is-contract-testing"></a>What is Contract Testing</h1><div class="paragraph"> <p>In order to increase the certainty that our systems behave properly, we write different types of tests. According to the <a href="https://martinfowler.com/bliki/TestPyramid.html">test pyramid</a> the main types of tests are unit, integration, and UI. The more complex the tests, the more time and effort they require and the more brittle they become.</p> </div><div class="paragraph"> <p>In a distributed system, one of the most frequent problems is testing integrations between applications. Let’s assume that your service sends a REST request to another application. When using Spring Boot, you can write a <code>@SpringBootTest</code> in which you test that behavior. You set up a Spring context, you prepare a request to be sent…​ and where do you send it? You haven’t started the other application, so you get a <code>Connection Refused</code> exception. You can try mocking the real HTTP call and returning a fake response. However, if you do that, you do not test any real HTTP integration, serialization and deserialization mechanisms, and so on. You could also start a fake HTTP server (for example, <a href="http://wiremock.org">WireMock</a>) and simulate how it should behave. The problem here is that you, as a client of an API, define how the server behaves. In other words, if you tell the fake server to return text <code>testText</code> when a request is sent to endpoint <code>/myEndpoint</code>, it does just that, even if the real server does not have such an endpoint. In short, the problem is that the stubs might not be reliable.</p> </div>