Events: Love Triangle in Integration Testing

Events appear as a solution to decouple some aspects of your system and not wait for an answer, like making a synchronic request. Everything is great when you start to use events, but what happens when you need to test if the entire application works fine when it receives an event? What happens if you need to load the database with certain information and validate that the event changes some information?

Some years ago, events appeared in the IT world with the idea of decoupling many applications or microservices, improving performance, reducing complexity, and allowing change flows. Some companies adopted this new paradigm instead of the classic synchronic world where the client needs to wait until the provider answers; initially, everything looked fine, but after some months, the problems appeared.

The developers adopted this new paradigm to reduce the complexity but, at the same time, introduced another problem in how to test the application simply. What happens if the events need to modify or read some information for a database? How can we check if the information in the database was modified?

This talk will delve into the main problems of not creating integration tests that check whether the application works fine, showing different alternatives with the pros and cons of each of them. You will see how to create integration tests that check if some scenarios work on an application that uses MongoDB, and SQS combined with Karate.

Target audience is QA, mid-developers, or up with a certain level of experience with events and Java applications. Understanding some specific framework or library is unnecessary because the idea is to show an agnostic solution you can apply to any Java / Kotlin application.