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.

[artur-ciocanu]

@salaboy I have moved all the helper classes to internal, so it is easier to signal that these are internal classes that end users should not use.

@siri-varma and @javier-aliaga let me know your thoughts. Once this is merged I will open PRs to move other ITs to use this new approach.

[cicoyle]

lgtm 🎉

[codecov]

Codecov Report

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

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1610      +/-   ##
============================================
+ Coverage     76.91%   78.90%   +1.98%     
- Complexity     1592     2074     +482     
============================================
  Files           145      227      +82     
  Lines          4843     6256    +1413     
  Branches        562      684     +122     
============================================
+ Hits           3725     4936    +1211     
- Misses          821      972     +151     
- Partials        297      348      +51     

☔ 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.