TDD for Microservices Architectures
Speaker: Reshmi Krishna and Vinay Upadhya
See list of all blog posts from conference

Showed Martin Fowler’s testing pyramid (unit, integration, component, end-to-end, exploratory) to set vocabulary

Focus with microservices is contract based testing.

Consumer driven contracts (CDC) let the callers specify exactly what they are interested in from a generic API. If everyone does this, you know who uses what fields so don’t remove something that a caller is relying on.

Spring Cloud Contract

• specifies contracts with Groovy (but mainly DSL so like data structure). Can use other formats such as XML
• Looks like BDD – request/response except HTTP level.
• Contracts stored with app under src/test/resources. Or can store in separate project
• The producer autogenerates stubs/tests and shares with consumer

Libraries

1. Spring Cloud Contract Verifier – checks service isn’t breaking any consumer contracts
2. Spring Cloud Contract Wiremock – wrapper around wiremock (wiremock is an API mocking tool)
3. Spring Cloud Contract Stub Runner – pulls stubs from maven and run with wiremock

Flow

1. Client app needs an API/field. Client writes test specifying what need. The test specifies workOffline = true to use local stub
2. Client implements code to call the microservice that implements the new feature [This was worded a “client implements the feature” which is not what they meant upon a few questions and confused me. With my wording (about calling the microservice and seeing the code it makes sense that the client is not implmenting the feature]
3. Client clones producer repo and define locally – if needed. Or can use common repo for contracts.
4. Autogenerates tests/stubs for producer based on contracts. The stubs are wiremock JSON. The tests use JUnit/AssertJ.
5. Client runs verifier tests – now they pass

If later version of service, update URL with version number so have new requirements.

The PowerPoint felt a bit rushed, but the demo was a good pace. I would have liked more mapping between the points in the flow. It’s a lot to remember. But it did mostly come together in my mind. Especially after I asked enough questions to uncover the a bullet in the flow wasn’t actually what happens. (So confused me) From the questions, I could tell that others in the audience were wondering about some details as well. Luckily, I had the step in this post for reference!