testing microservices join the revolution

src: Testing Microservices: Join the Revolution By Victor Rentea

Abstract

The test pyramid was created during the time of monolith. Now, with microservice, we should use honeycomb testing strategy. microservice now faces other types of bugs:

• have more APIs ⇒ stable test surfaces
• hide less code complexity
• face more configuration risk

What bugs can slip past unit test?

• Actual behavior of A does not match the mock(A).
• Bad @Query semantic.
• Framework magic fails to work: @Transactional, @Cacheable, @Secured, @EventListener
• Misconfigured libary: Rabbit, Resilience4j, …

The speaker recommends using integration tests to give use confidence on those types of bugs. However, there are some caveats:

• Slow spring application startups, which leads to slow tests.
  • Exploit shared spring context.
• Use real database using testcontainers.
• Use tools like wiremock to simulate real HTTP calls to verify the endpoint, the deserialization of the DTO, …
• Avoid coupled tests, i.e. one test case that affect another, like inserting the same line in the database, by:
  • cleaning up the database after/before each test case,
  • use SQL queries to clean up,
  • use @Transactional on the test class, and let spring testing framework to rollback the transaction,
  • use different values when inserting rows in the database (test data slice).

Take away:

• Test isolation: clean up after or test data slices.
• Flaky tests: block or poll; test async part separately.
• Slow tests: reuse expensive resources.
• Cognitive load: build a testing DSL (framework).

Reviews

2024-07-19

I saw this speaker Victor Rentea in multiple talks. His sessions are always lively (albeit a bit too much with his pre-recorded sounds). He recommends some concrete actions that are actionable in a day-to-day work, contrary to some of his peers where their content are more abstract. We can say he offers some “tactical” advice on software engineering.