Add automatic tests with the Otel Spring Boot starter and some library instrumentations

[jeanbisutti]

Today, the integration of the OTel Spring Boot starter with some instrumentation libraries (Logback, JDBC, ...) is not automatically tested, which can lead to this type of issue.

What do you think about the addition of a spring-boot-autoconfigure-lib-test folder here to contain this kind of tests?

The tests would use in memory collectors at first and not a fake server (as done here) . The tests mechanims could be improved in another steps. It would be interesting to also run these tests in as Spring GraalVM native tests.

[mateuszrzeszutek]

Would it make sense to add a smoke test for the spring starter? We could reuse some of the common logic for collector/fake backend setup

[jeanbisutti]

Would it make sense to add a smoke test for the spring starter? We could reuse some of the common logic for collector/fake backend setup

The smoke test mechanism does not fill well with the Spring native tests (gradle nativeTest) for which Spring creates the tests as a native executables and launches them.

The collector/fake backend setup might be reused with some refactoring in the new test folder. I would also need to check things with Spring native tests and Tescontainers. That's why I propose to start with in memory collectors to start having tests for the OTel Spring starter and instrumentation libraries, that will be executed with JVMs and as native executables.

[trask]

Would it make sense to add a smoke test for the spring starter? We could reuse some of the common logic for collector/fake backend setup

The smoke test mechanism does not fill well with the Spring native tests (gradle nativeTest) for which Spring creates the tests as a native executables and launches them.

I think the idea with using the smoke test infra would be to build a full native Spring app, and then hit endpoints and verify results (instead of running gradle nativeTest).

[jeanbisutti]

My understanding of the smoke tests is that images with application (for example, a Spring Boot application) are built and deployed once. After, for each test execution, the smoke test pulls an image and injects the Java agent under development into the Docker container.

With the OpenTelemetry Spring Boot starter, the instrumentation of the starter is part of the application. So, to test the starter under development, it would require for example to modify the smoke test mechanism to rebuild the image for each test execution. It may not be a simple modification.

Other aspects to consider are test speed, test stability, and resources (CPU and memory) required to execute the test. With gradle nativeTest the test is transformed into a native executable (not an image), and after Spring Boot executes this native executable. Creating a Spring native image with gradle bootBuildImage requires more resources and can sometimes fail from my experience.

[jeanbisutti]

Fixed with #8965