Как я могу протестировать метод получения подписчика в кластере Akka?

У меня есть следующий абстрактный базовый класс Subscriber:

abstract class Subscriber(topics: Seq[String]) extends Actor with ActorLogging {
  import DistributedPubSubMediator.{ Subscribe, SubscribeAck }

  val mediator = DistributedPubSub(context.system).mediator

  // subscribe to each topic
  topics.foreach{mediator ! Subscribe(_, self)}

  def receive = {
    case SubscribeAck(Subscribe(name, None, `self`)) ⇒
      log.info(s"Subscribing to $name")
  }
}

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

val topic = "foo"

class FooSubscriber extends Subscriber(Seq(topic))

val fooSubActor = system.actorOf(Props[FooSubscriber])    
val mediator = DistributedPubSub(system).mediator
val msg = "This is a string"

// Publish the msg to the "foo" topic.
mediator ! Publish(topic, msg)

fooSubActor.expectMsg(msg)

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

Как правило, в документах Akka много примера кода с соответствующими наборами тестов, но я не смог найти ничего в документации Akka Cluster, связанной с тестированием метода receive.

У кого-нибудь есть предложения?


person erip    schedule 01.01.2017    source источник
comment
Кладж состоит в том, чтобы переопределить receive и изменить переменную-член, когда актор что-либо получает, и сделать утверждение, что переменная-член установлена ​​в моем тесте... но это плохо. Ищем более идиоматический подход к тестированию.   -  person erip    schedule 04.01.2017


Ответы (1)


Это хрестоматийный пример того, как внедрение зависимостей помогает с тестируемостью.

Если вы получаете посредник для DistPubSub в конструкторе подписчика, а не запрашиваете его напрямую, вы можете просто протестировать актор Suscriber изолированно, без необходимости использовать DistPubSub как часть вашего тестового приспособления.

person emilianogc    schedule 04.01.2017
comment
Проблема не в посреднике — проблема в ожидании получения сообщения подписчиком. - person erip; 04.01.2017
comment
Но в этом случае вы действительно тестируете только расширение PubSub, а не логику вашего актера. - person emilianogc; 05.01.2017
comment
Не правда. Возможно, вы не поняли моего вопроса — я пытаюсь проверить логику своего актера. Посредник не зависит от подписчика, поэтому вы должны использовать PubSub в первую очередь - чтобы избежать обязательного отслеживания того, кто публикует. - person erip; 05.01.2017
comment
В примере, который вы предоставляете, единственная логика, присутствующая для вашего субъекта-подписчика, заключается в подписке на определенные темы и регистрации при получении подтверждения. В тестовом примере вы утверждаете, что подписчик получает сообщение после публикации в системе PubSub. Но это не ответственность подписчика, а только PubSub, поэтому вы только утверждаете, что PubSub повторно отправляет сообщения. С другой стороны, ответственностью подписчика является подписка на темы, поэтому, если вы отправляете TestProbe для посредника, вы можете утверждать, что он действительно отправляет сообщения о подписке. - person emilianogc; 05.01.2017