AsyncEventBus Guava в тестах

Question

В нашем коде часто используются сообщения, путешествующие на гуаве AsyncEventBus.Теперь, в некоторых тестах некоторый трафик сообщений должен завершиться, прежде чем утверждать о состоянии тестируемого (скажем, некоторые загрузки запланированы на EventBus, и они должны завершиться, чтобы мы могли проверить, были ли загружены вещиправильно).

К сожалению, на данный момент это обрабатывается ужасным подходом Thread.sleep(delay);;очень хрупкие и делающие тесты облупленными.

Каким будет правильный способ проверки кода в зависимости от завершения операций над общим AsyncEventBus?

Answer 1

То, что я делаю в сквозных или интеграционных тестах (с участием нескольких потоков), где мне нужно ждать, пока событие не произошло, использует CountDownLatch.Я бы держался подальше от спящих потоков, как вы уже упоминали.

Это требует, чтобы в вашем тестовом коде вы могли подключить метод CountDownLatch.countDown() к методу обратного вызова, который будет вызывать EventBus.Я объясню это на коротком примере:

class SomeEventReceiver {
   ...
   @Subscribe public void doSomethingFoo(BarEvent e) {
      // your logic
   }
   ...
}

// Unit test
...
CountDownLatch readyToAssert = new CountDownLatch(1); // could be 2 or more depending on your needs
SomeEventReceiver rec = new SomeEventReceiver(...) { // create an anonymous subclass
   @Subscribe
   @Override
   public void doSomethingFoo(BarEvent e) { // override super method
      super.doSomethingFoo(e); // execute super method's logic
      readyToAssert.countDown(); // signal your test method that it's ready to assert
   }
}
// put your events on the event bus and do all other necessary things
...
readyToAssert.await(); // JUnit thread is blocked until event handlers where called
assertXXX(...); // assert whatever needs to be asserted

Это мой личный подход при тестировании.Очевидно, что это легче сделать, если тестируемые классы спроектированы для тестирования.

Надеюсь, это помогло!