testing microservices join the revolution

src: Testing Microservices: Join the Revolution By Victor Rentea - Invidious

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.