Adding DaprSpringBootTest and DaprSidecarContainer annotation for easier ITs authoring

[artur-ciocanu]

Description

This PR adds two major improvements:

• DaprSpringBootTest that hides a lot of complexity related to SpringBootTest and Testcontainers
• DaprSidecarContainer that takes care of adding all the nitty gritty details for Dapr container and Spring Boot

Currently only a single IT has been migrated to showcase how things are looking.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: N/A

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[artur-ciocanu]

@dapr/maintainers-java-sdk and @dapr/approvers-java-sdk could you please take a look. I think this is a really important improvement for ITs and Testcontainers integration.

@salaboy and @javier-aliaga could you please take a look. Thank you.

[salaboy]

@artur-ciocanu great stuff.. as always..
The main reason why I didn't do something like this before is because I think, with this we push Spring Users to learn Dapr specific stuff.. I always thought by exposing the DaprContainer as a single entry point that you can define as you define PostgreSQLContainer or RedisContainer will make Dapr easier to consume without learning a lot of stuff.

I am not saying that these improvements are not good. I am just worried on going too deep into simplifications where it looks odd for spring users. For example @DaprSpringBootTest(classes = {TestActorsApplication.class, TestDaprActorsConfiguration.class}) this doesn't look friendly in my opinion.. I wonder if we can just use the normal annotation but do more magic behind the scenes if the Dapr dependencies are in the classpath, instead of pushing the user to think in terms of @DaprSpringBootTests.. as they already have @SpringBootTests in their applications.
Now if this annotation @DaprSpringBootTests is for our internal tests, we need to make sure that this doesn't leak to the users as prefered way to write their tests.

[artur-ciocanu]

@artur-ciocanu great stuff.. as always.. The main reason why I didn't do something like this before is because I think, with this we push Spring Users to learn Dapr specific stuff.. I always thought by exposing the DaprContainer as a single entry point that you can define as you define PostgreSQLContainer or RedisContainer will make Dapr easier to consume without learning a lot of stuff.

I am not saying that these improvements are not good. I am just worried on going too deep into simplifications where it looks odd for spring users. For example @DaprSpringBootTest(classes = {TestActorsApplication.class, TestDaprActorsConfiguration.class}) this doesn't look friendly in my opinion.. I wonder if we can just use the normal annotation but do more magic behind the scenes if the Dapr dependencies are in the classpath, instead of pushing the user to think in terms of @DaprSpringBootTests.. as they already have @SpringBootTests in their applications. Now if this annotation @DaprSpringBootTests is for our internal tests, we need to make sure that this doesn't leak to the users as prefered way to write their tests.

@salaboy your suggestion is that we do not try to compose annotations, so we do not confuse SpringBoot users. I get your point.

I wanted to make sure that we can simplify some of this random port and sidecar dependency, but I guess since we want it just for us we can push it to it as a helper, outside of the Dapr Testconainer module, what do you think?

[salaboy]

Yeah so let's split what the end user will use to create end user tests and the functionality that we want to have for our own tests to make them easier

[artur-ciocanu]

@salaboy the helper annotations and classes have been moved to "sdk-tests" module, now these should not conflict with "testcontainers-dapr" module.

Let me know your thoughts.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.65%. Comparing base (d759c53) to head (7212700).
⚠️ Report is 243 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1610      +/-   ##
============================================
+ Coverage     76.91%   78.65%   +1.74%     
- Complexity     1592     1958     +366     
============================================
  Files           145      217      +72     
  Lines          4843     5970    +1127     
  Branches        562      661      +99     
============================================
+ Hits           3725     4696     +971     
- Misses          821      934     +113     
- Partials        297      340      +43     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.