Improve test context cleanup

[MarcoMartins86]

Type: Feature

Is your feature request related to a problem? Yes
While performing sequential IT tests, I often encounter the issue where the SQSListener bean is not cleared between tests, which makes it challenging to conduct real IT tests.

Describe the solution you'd like
Ability for the Spring Cloud AWS test context to be cleaned between test classes without the use of @DirtiesContext.

Describe alternatives you've considered

• Using the @DirtiesContext works, but then tests will take much more time to run.
• Doing almost the full IT. Bypassing the first step of sending the message to the localstack SQS and doing it by calling the listener method with the object directly.

Additional context

1. I have a replicator project where to replicate this issue, I need to launch a WireMock server per test class, and if I don't do it, the issue doesn't happen. However, this is happening to me in other, more complex projects that don't use WireMock, which I can't share. That's why I think this is a behavior with Spring Cloud AWS.
2. The replicator https://github.com/MarcoMartins86/spring-issue-replicator#
3. Run mvn clean install, the test that fails is where the issue is happening, and we can see in the output something like Listener from [Test1] consuming message from [Test3], which means that the bean of another test was not destroyed between test classes and consumed the message.
4. You can uncomment the //@DirtiesContext in IntegrationTest and run again to see they will all pass now.
5. Please do take a look. Thank you.

[tomazfernandes]

Hey @MarcoMartins86, thanks for bringing this up.

Once a container is launched it'll keep running until the context is closed and signals it to stop. You could change that behavior by manually starting and stopping containers in Before and After JUnit hooks, or in the tests themselves.

One other possibility would be having separate queues for each test, which is what we use in our integration tests in the project.

A more involved approach would be creating a JUnit extension that would stop containers automatically after the test suite is done, but that might be tricky if we're running multiple tests in parallel.

Let me know if that helps.

[MarcoMartins86]

Hey @tomazfernandes, my problem is with the bean of the class where the @SqsListener annotation resides, not the container.

If I'm not mistaken, on sequential tests, beans between test classes should be dropped and recreated by the Spring test context, at least this is the behavior that I observe with all other beans. However, the bean that contains the @SqsListener lives throughout his test context lifetime, and bleeds into the other ones, so basically we end up with multiple instances of that bean, and that shouldn't be possible because it's a singleton.

Even if the localstack container is always up (my intended behavior), I was expecting that the @SqsListener would drop its connection when the Spring test context was being cleaned up so it could "die" gracefully.

[maciejwalkowiak]

As far as i can tell this is a common problem among all Spring messaging related interactions - RabbitMQ for example.

[MarcoMartins86]

Ok, I understand now, this is a lot deeper than this library alone. I had no idea since it was the first time I noticed the "weird" behavior.

I think I will also adopt the unique queue per test approach workaround, and as a bonus, it will allow test parallelism if needed.

Thanks @tomazfernandes and @maciejwalkowiak for the insights.