grpc-ecosystem
`@DirtiesContext` is required on every test
The context
The need for @DirtiesContext on all unit tests using a grpc service created by this starter greatly slows down tests, and doesn't feel like a proper solution as applications scale.
The bug
What's the problem? What's not working? What do you expect to happen.
all @SpringBootTest classes also require @DirtiesContext in order for tests across the application to function propertly.
Is there a stacktrace or a hint in the logs? (very important) Screenshots work as well, but don't screenshot your logs.
Steps to Reproduce
Steps to reproduce the behavior:
- Create an application using gRPC services.
- Write 2 or more
@SpringBootTestclasses - Run your project's tests. These test classes will compete and your tests will fail.
Workaround, add @DirtiesContext to each test, but, this greatly slows down execution time of your application tests.
The application's environment
Which versions do you use?
- Spring (boot):
- grpc-java:
- grpc-spring-boot-starter:
- java: version + architecture (64bit?)
- Other relevant libraries...
These versions don't really matter - it's a core issue with this library that is seemingly well documented, but there has to be a better way?
Additional context
- Did it ever work before?
No
- Do you have a demo?
No, but this issue is seemingly well documented with this project, but @DirtiesContext feels like a workaround instead of a solution.
Spring Boot has to deal with this with normal HTTP servers (netty, tomcat, etc.) so it should be possible to copy what we do there. One thing we do for sure is start the server on a random port to avoid the clashes that seem to be the main problem for people using gRPC. It might mean that we need a new grpc-spring-boot-test jar to carry the necessary test utilities.
Is it perhaps a bit of a smell that none of the example apps in this project have tests? Some more dogfooding would probably be healthy.
Adding a new jar file is quite a big change. Probably the project maintainers should give a clear signal that this is a welcome addition. Adding tests to all examples would be a big change as well. Maybe we should start with one test so we can agree on what works?
I played around with this a bit. I still think starting on a random port would be useful, but I found this nice library: https://github.com/asarkar/grpc-test. You just have to declare each test class with @ExtendWith(GrpcCleanupExtension.class). Neat.
However, I also haven't found a way to see a failure that only @DirtiesContext fixes. Is there a sample somewhere that someone can point me to? @Bwvolleyball do you have one?
UPDATE: I can reproduce the problem - you need 2 tests with different application contexts (so add a nested @Configuration or extra configuration in @SpringBootTest). Definitely should be solved using a random port (but see #826 for wider context).