Плохой тест JUnit с использованием springframework имеет хрупкие вызовы Thread.sleep ().Как исправить?

Question

Я недавно присоединился к группе с серьезными проблемами тестирования JUnit. Одна проблема - это 8-минутный тест! Тест состоит из нескольких разделов; каждый делает вызовы org.springframework.context.ApplicationEventPublisher.publishEvent () затем Thread.sleep () различного времени, затем проверяются условия.

Есть несколько очевидных проблем с этим подходом, время вызовов Thread.sleep () хрупкое:

• тесты иногда дают сбой на загруженных машинах; и

• тесты занимают слишком много времени, когда они не проходят.

Доступен ли для тестирования пул, в котором обрабатываются эти события, и есть ли вызов, чтобы узнать, прекратился ли каскад событий?

Answer 1

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

Answer 2

Вы можете перезаписать значение по умолчанию applicationEventMulticaster, добавив этот идентификатор компонента в контекст приложения.

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

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

Интересно, что JavaDoc для SimpleApplicationEventMulticaster, который по умолчанию используется Spring при использовании ApplicationContext, гласит следующее:

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

Answer 3

Я (намеренно) избегаю Spring, поэтому я не уверен, что смогу помочь со спецификой, но, просто взглянув на проблему сна, вы можете использовать что-то вроде WaitFor в tempus-fugit (бесстыдная вилка) для опроса Condition, а не «спать и надеяться».Это не идеально, и обычно изменение в способе тестирования (как предлагалось ранее) является предпочтительным, но это означает, что вы получите более мелкозернистые «ожидания», которые с большей вероятностью позволят избежать тестовых условий / нестабильных тестов и в целом ускорить тестирование.

См. документацию по проекту для получения подробной информации и отправку сообщения, если вы найдете это полезным!