Lecture 261: Introduction to microservices testing

Have you ever tried to fix a clock with a dozen moving gears? That's pretty much what testing microservices feels like — you're juggling a lot of interconnected parts. One failure can affect the whole system, like the old "domino theory." So let's talk about testing approaches that help you avoid nasty surprises.

In a microservice architecture testing is critical, since each service is an independent piece that talks to others. And all those interactions need to be verified.

Differences between testing monoliths and microservices

Testing microservices is tricky because they aren't just a bunch of classes and methods inside one system. Unlike a monolith, microservices:

• Are distributed: requests travel over the network, which can introduce latency or failures.
• Have many interaction points: each service talks to N other services.
• Run asynchronously: it's not as simple as a synchronous method call.

For microservices we use a broader toolset and adapt standard testing approaches.

Types of testing for microservices

1. Unit tests (Unit Testing): we check individual methods and components inside a single service. It's like testing each gear in the mechanism separately.
2. Integration tests (Integration Testing): we test how a service interacts with infrastructure components or other services.
3. Contract testing (Contract Testing): make sure consumers of a microservice understand its API the way it's intended.
4. System testing: verify whether the whole system works correctly end-to-end.
5. Asynchronous testing: test queues and messages sent/received via Kafka, RabbitMQ, and other brokers.
6. Load testing (Load Testing): check if the system handles production-like load. Who among us doesn't enjoy watching an app "suffer" under load?

Main challenges in testing microservices

Now that we're slightly pumped, let's talk about the problems. Spoiler: you can't avoid them entirely.

1. Complexity of interactions
   You have many services, each of which may talk to databases, APIs, message queues, and other services. If one of them "falls over," it can break the whole system.
2. Asynchronicity
   Asynchronous processing of messages and events is a headache. You need to handle timing issues and ordering.
3. Test isolation
   "Tests shouldn't depend on each other," someone wise said. But in real life it's hard to get true isolation, especially when working with databases or third-party APIs.
4. Realism of tests
   The "butterflies and unicorns" mode is off. Making tests realistic (for example using real databases instead of in-memory ones) takes extra effort.

Approaches to testing microservices

1. Layered testing strategy
   In a microservice architecture it's useful to follow the testing pyramid:
   • Unit tests: the foundation. You should have the most of these.
   • Integration tests: fewer in number, but vital for checking interactions.
   • E2E tests: the rarest, since they take the most time and are harder to set up.

   
   E2E tests
   Integration tests
   Unit tests
   

2. Containerization for isolation
   Use Docker and Testcontainers to spin up the services and databases you need during tests. That gives you realism.
3. Contract testing
   Define contracts for interactions between services. That helps avoid misunderstandings — "I'll send JSON, and what you receive is your problem" doesn't sound great, right?

Tools for testing

• JUnit 5
  A classic. The standard framework for unit testing in Java.
• Mockito
  A developer's best friend! Create mocks and stubs so tests stay isolated from external dependencies.
• Spring Boot Test
  Spring's tools for integration testing. Help you test in conditions close to production.
• MockMvc
  Used for testing REST APIs: you can "simulate" HTTP requests without a real server.
• Pact
  For contract testing between microservices.
• Testcontainers
  Brings up Docker containers right inside your tests.
• Kafka Test Utils
  For testing messages in Kafka.

A real-world example: what can go wrong?

Imagine we have two microservices: OrderService and InventoryService. OrderService handles orders, and InventoryService manages stock. OrderService sends a REST request to InventoryService to check if the item is in stock.

Now imagine: we updated OrderService but forgot to check whether InventoryService's API changed. Result: OrderService calls an endpoint that InventoryService no longer supports. That's not just a rare bug — it can cause real chaos in production. Solution? Always use contract testing!

Conclusion

Testing microservices can feel like a puzzle — and that’s true, but only until you start using the right tools and approaches. This intro gives you an idea of why it matters and what problems we solve. The fun part comes next — practice! Theory without hands-on code stays just words.

In the next lecture we'll start with unit testing for microservices, where you'll write your first test cases yourself. So — ready?