1

We are trying to use Feign + Ribbon in one of our projects. In production code, we do not have a problem, but we have a few in JUnit tests.

We are trying to simulate number of situations (failing services, normal runs, exceptions etc.), hence we need to configure Ribbon in our integration test many times. Unfortunately, we noticed that even when we destroy the Spring context, part of the state still survives probably somewhere in static variables (for example: new tests still connect to balancer from the previous suite).

Is there any recommended way, how to purge the static state of both these tools? (something like Hystrix.reset())

Thanks in advance!

We tried to reset JVM after each suite - it works perfectly, but its not very practical (we must set it up in both Gradle and Idea (as Idea test tunner does not honor this out of the box)). We also tried renaming the service between tests - this works on lets say 99% (it sometimes fails for some reason...).

g00glen00b
  • 41,995
  • 13
  • 95
  • 133
malejpavouk
  • 4,297
  • 6
  • 41
  • 67
  • The issue still seems not resolved. I've just faced this with ribbon 2.3.0, hystrix-core 1.5.18, open feign 10.2.3, Spring Boot 2.1.9 or 2.1.17. Different tests using `@SpringBootTest`, having separate Spring application context with different properties, are affected as Feign client uses configuration somehow cached by Ribbon/Feign (?) at the runtime of the first of such tests. All tests when run one by one are correct. – Krzysztof Tomaszewski Sep 29 '20 at 15:30

1 Answers1

0

You should submit a bug to Ribbon if it is the case that there is some static state somewhere. Figure out what minimal code causes the issue, if you are not able to do that though then they won't do anything. In your code base you should do a search for any use of static which is not also final and refactor them as well if any exist.

Furthermore you may find it useful to make strong distinctions between the various different types of tests. It doesn't sound like you are doing a unit test to me. Even though you are just simulating these services, and simulating failures, this sort of test is really an integration test, because you are testing if Ribbon is configured correctly with your own components, which is really an integration test. It would be a unit test if you would test only that your component is configuring Ribbon correctly, not sure if I made sense there haha it's a subtle distinction but it has large implications in your test.

On another note don't dismiss what you have now as necessarily a bad idea. It may be very useful to have some heavy weight integration tests checking the behaviour of Feign if this is a mission critical function, IMO it's a great idea in that case. But it's a heavy weight integration test and should be treated as such. You might want to even use some container magic ect to achieve this sort of test, with services which fail in your various different failure scenarios. This would live in CI and usually developers wouldn't run those guys with each commit unless they were working directly with a piece of functionality concerning integration.

Derrops
  • 7,651
  • 5
  • 30
  • 60