search

spring-cloud / spring-cloud-stream

Framework for building Event-Driven Microservices
http://cloud.spring.io/spring-cloud-stream
Apache License 2.0
1.01k stars 614 forks source link

TestChannelBinderConfiguration does not respect auto restart configuration for bindings #2079

Open tobske opened 3 years ago

tobske commented 3 years ago

Setting the auto restart configuration to false on consumers in the following way doesn't have an effect on the TestChannelBinder.

--spring.cloud.stream.default.consumer.autoStartup=false

I try to write an tests where at startup the bindings are deactivated and then get activated through the BindingsEndpoint but actually the bindings are always started directly in the TestChannelBinder.

olegz commented 3 years ago

Test channel binder was never designed for these type of features. While I am not against supporting it it would not be of high priority, so would be ideal for community contribution.

Out of curiosity, what kind of test you are writing where you need to verify this auto-startup? What I mean is that that is the feature guaranteed by the framework so we have tests for it in binders, so why do you need to test the functionality of the framework?

tobske commented 3 years ago

Thanks for responding so fast. To speak more verbosely:

We have a service that consumes messages coming in from Kafka but the service shouldn't consume the messages before some caches are filled after start up. That is why we start the service with autoStartup=false for the bindings and then call bindingsEndpoint.changeState(binding, BindingsEndpoint.State.STARTED) on every binding as soon as the caches are filled. This setup is very similar to a starting pod in kubernetes that is life but not ready which results in a load balancer that won't send API requests to that pod.

What we are now trying to test is that we are successfully starting the bindings as soon as the caches are filled. We could mock the BindingsEndpoint for that but in that case the tests wouldn't get red if for example the property autoStartup or the BindingsEndpoint are changed.

I hope that makes a bit clearer and I understand that this feature is not the one with the highest priority.

olegz commented 3 years ago

Well, I am still having a bit of an issue with this. The autoStartup contract is provided and guaranteed by the framework, so we (Spring) test it. So why do you believe you need to have a test to test the framework's functionality?