🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
During our Live Q&A Session, we answered these questions. Well, I started with the first question, and it expanded to fill the whole session.
What do most developers think an integration test is?
Suppose we have the Ordering Microservice, which communicates with PayPal, SAP and also with the Catalog Microservice, which depends on the Product Microservice.
The way that most developers will write up the integration test for the Ordering Microservice is:
Spin up real instance of the target Microservice (Ordering Microservice)
Spin up all of its transitive dependencies (PayPal, SAP, Catalog Microservice, Product Microservice).
This kind of test is like an E2E test… indeed, we could see an E2E test as an integration test targeting the Frontend, and spanning the whole transitive dependency graph.
Why is this kind of integration test problematic?
When this kind of “integration test“ for Ordering Microservice fails, we cannot isolate the fault. We don’t know if the problem is in the Ordering Microservice or PayPal or SAP or Catalog Microservice or Product Microservice, or perhaps a combined problem across all of these. All of these teams have to get together, do some tracing & debugging, to find out which team is at fault.
It also means that if for whatever reason an external system is unavailable (e.g. SAP test Instance is unavailable) or some dependent microservice is unavailable (e.g. Catalog Microservice is unavailable), then the Ordering Microservice team can NOT run the Ordering Microservice Integration Test, they’re blocked.
So what’s the solution?
As I explained in the Live Q&A session, the solution is:
