-
Notifications
You must be signed in to change notification settings - Fork 905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add automatic tests with the Otel Spring Boot starter and some library instrumentations #8776
Comments
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 ( 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. |
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 |
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 |
Fixed with #8965 |
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.
The text was updated successfully, but these errors were encountered: