Имитация с лентой: сброс

Мы пытаемся использовать Feign + Ribbon в одном из наших проектов. В производственном коде у нас нет проблем, но у нас есть несколько в тестах JUnit.

Мы пытаемся смоделировать ряд ситуаций (сбой служб, нормальный запуск, исключения и т. д.), поэтому нам нужно много раз настраивать ленту в нашем интеграционном тесте. К сожалению, мы заметили, что даже когда мы уничтожаем контекст Spring, часть состояния все еще сохраняется, вероятно, где-то в статических переменных (например: новые тесты все еще подключаются к балансировщику из предыдущего набора).

Есть ли рекомендуемый способ, как очистить статическое состояние обоих этих инструментов? (что-то вроде Hystrix.reset())

Заранее спасибо!

Мы пробовали сбрасывать JVM после каждого пакета — он отлично работает, но не очень практичен (мы должны настроить его как в Gradle, так и в Idea (поскольку тестовый тюнер Idea не поддерживает это из коробки)). Мы также пробовали переименовывать службу между тестами - это работает, скажем, на 99% (иногда по какой-то причине происходит сбой...).


java spring feign netflix-ribbon netflix-feign
person malejpavouk    schedule 31.07.2017    source источник
comment
Проблема все еще кажется не решенной. Я только что столкнулся с этим с лентой 2.3.0, hystrix-core 1.5.18, open feign 10.2.3, Spring Boot 2.1.9 или 2.1.17. Различные тесты, использующие @SpringBootTest, имеющие отдельный контекст приложения Spring с разными свойствами, затронуты, поскольку клиент Feign использует конфигурацию, каким-то образом кэшированную Ribbon/Feign (?) во время выполнения первого из таких тестов. Все тесты при запуске один за другим корректны.   -  person Krzysztof Tomaszewski    schedule 29.09.2020

Ответы (1)


arrow_upward
0
arrow_downward

Вы должны отправить сообщение об ошибке на ленту, если где-то есть какое-то статическое состояние. Выясните, какой минимальный код вызывает проблему, если вы не можете этого сделать, тогда они ничего не сделают. В вашей кодовой базе вы должны выполнить поиск любого использования статики, которое также не является окончательным, и также реорганизовать их, если они существуют.

Более того, вы можете счесть полезным проводить четкое различие между различными типами тестов. Не похоже, что вы делаете модульный тест для меня. Несмотря на то, что вы просто имитируете эти сервисы и имитируете сбои, такой тест на самом деле является интеграционным тестом, потому что вы проверяете, правильно ли настроена лента с вашими собственными компонентами, что на самом деле является интеграционным тестом. Это был бы модульный тест, если бы вы проверили только то, что ваш компонент правильно настраивает ленту, не уверен, что у меня есть смысл, ха-ха, это тонкое различие, но оно имеет большое значение в вашем тесте.

С другой стороны, не отвергайте то, что у вас есть сейчас, как обязательно плохую идею. Может быть очень полезно иметь несколько тяжелых интеграционных тестов, проверяющих поведение Feign, если это критически важная функция, IMO, в этом случае это отличная идея. Но это сложный интеграционный тест, и к нему следует относиться как к таковому. Возможно, вы даже захотите использовать некоторые контейнерные магические действия для проведения такого рода испытаний со службами, которые терпят неудачу в различных сценариях сбоев. Это будет жить в CI, и обычно разработчики не будут запускать этих парней с каждым коммитом, если только они не работают непосредственно с частью функциональности, связанной с интеграцией.

person Derrops    schedule 01.08.2017