In my Spray route, I delegate to an actor to process the request. The RequestContext is sent in the message to that actor.
path("mypath") {
parameters("thing".as[String]) { thing => ctx =>
myActor ! ProcessThingAndResondToContext(thing, ctx)
}
}
In my test, I substitute a TestProbe for the actor, because the actor's processing is expensive.
class MySpec extends Specification with Specs2RouteTest with ScalaCheck with MyService {
val testProbe = TestProbe()
override val myActor = testProbe.ref
def is = s2"""
it should $doTheRightThing
"""
def doTheRightThing = {
Get(s"/mypath?thing=fruit") ~> route ~> check {
testProbe.expectMsgClass(classOf[ProcessThingAndResondToContext])
status mustEqual StatusCodes.Success
}
}
This spec fails because there's no status. The TestProbe does nothing and so the ctx was never responded to.
Request was neither completed nor rejected within 1 second
The line status mustEqual StatusCodes.Success is not crucial to my test, but I can't remove it because then the spec doesn't compile - the method no longer typechecks as a MatchResult.
How can I test the route delegated to the actor?
I didn't solve the question, but resolved my problem by using a TestActorRef instead of a TestProbe. Then I could specify a simplified behaviour and still respond to ctx.
Related
#Singleton
class EventPublisher #Inject() (#Named("rabbit-mq-event-update-actor") rabbitControlActor: ActorRef)
(implicit ctx: ExecutionContext) {
def publish(event: Event): Unit = {
logger.info("Publishing Event: {}", toJsObject(event), routingKey)
rabbitControlActor ! Message.topic(shipmentStatusUpdate, routingKey = "XXX")
}
}
I want to write a unit test to verify if this publish function is called
rabbitControlActor ! Message.topic(shipmentStatusUpdate, routingKey = "XXX")
is called only once.
I am using spingo to publish messages to Rabbit MQ.
I am using Playframework 2.6.x and scala 2.12.
You can create an TestProbe actor with:
val myActorProbe = TestProbe()
and get its ref with myActorProbe.ref
After, you can verify that it receives only one message with:
myActorProbe.expectMsg("myMsg")
myActorProbe.expectNoMsg()
You probably should take a look at this page: https://doc.akka.io/docs/akka/2.5/testing.html
It depends you want to check only the message is received by that actor or you want to test the functionality of that actor.
If you want to check message got delivered to the actor you can go with TestProbe. I.e.
val probe = TestProbe()
probe.ref ! Message
Then do :
probe.expectMsg[Message]
You can make use of TestActorRef in case where you have supervisor actor, which is performing some db operations so you can over ride its receive method and stop the flow to go till DB.
I.e.
val testActor =new TestActorRef(Actor.props{
override receive :Receive ={
case m:Message => //some db operation in real flow
//in that case you can return what your actor return from the db call may be some case class.
case _ => // do something }})
Assume your method return Future of Boolean.
val testResult=(testActor ? Message).mapTo[boolean]
//Then assert your result
I want to test that an actor A send a message to an actor B after have received a message.
I'm using Play! 2.5 and I use the factories since I need to inject some of my classes and things like wSClient inside the actors.
The Actor A looks like:
object ActorA {
trait Factory {
def apply(ec: ExecutionContext, actorBRef: ActorRef): Actor
}
}
class ActorA #Inject()(implicit val ec: ExecutionContext,
#Named("actor-b") actorBRef: ActorRef)
extends Actor with ActorLogging with InjectedActorSupport {
override def receive: Receive = {
case i: Long =>
log info s"received $i"
actorBRef ! (i+1)
}
And the actor B is even more simple:
object ActorB {
trait Factory {
def apply(): Actor
}
}
class ActorB extends Actor with ActorLogging {
override def receive: Receive = {
case _ =>
log error "B received an unhandled message"
}
}
But my test doesn't pass, it is said that the expected message doesn't arrive, I get a Timeout in the test (but it is well logged by the actor B) so the problem comes from the test (and probably the Probe).
Here is the test:
val actorBProbe = TestProbe()
lazy val appBuilder = new GuiceApplicationBuilder().in(Mode.Test)
lazy val injector = appBuilder.injector()
lazy val factory = injector.instanceOf[ActorA.Factory]
lazy val ec = scala.concurrent.ExecutionContext.Implicits.global
lazy val factoryProps = Props(factory(ec, actorBProbe.ref))
val ActorARef = TestActorRef[ActorA](factoryProps)
"Actor B" must {
"received a message from actor A" in {
ActorARef ! 5L
actorBProbe.expectMsg(6L)
}
}
I also created a minimum Play! application with the code above available here.
In your test, actorBProbe is not the ActorB ref passed to ActorA constructor (of ref ActorARef). What really happens is that Guice creates a different ActorB (named actor-b), and passes its ref to ActorA (of ref ActorARef) constructor.
The test ends up with ActorB actor-b receiving 6L (as evident in log). While actorBProbe receives nothing.
The confusion really comes from mixing Guice lifecyle with Actors. In my experience, it creates more pains than I can bear.
To prove, simply print hash code of ActorRef's, you'll see they are different. Illustrated as followings:
val actorBProbe = TestProbe()
println("actorBProbe with ref hash: " + actorBProbe.ref.hashCode())
And,
class ActorA ... {
override def preStart =
log error "preStart actorBRef: " + actorBRef.hashCode()
// ...
}
In fact, even ec inside ActorA is not the same ec in the test code.
The following is a way to "force" the test to pass and at the same time prove that actorBProbe wasn't really being used by ActorB.
In stead of relying on Guice to "wire in" ActorB, we tell Guice to leave it alone by replacing #Named("actor-b") with #Assisted, like this,
import ...
import com.google.inject.assistedinject.Assisted
class ActorA #Inject()(...
/*#Named("actor-b")*/ #Assisted actorBRef: ActorRef)
...
Re-run the test, it'll pass. But this is probably not what you wanted to begin with.
In my Scala application say I have Actor A and Actor B. I want to devise a test case in ScalaTest that would allow me to send a message to Actor A and see what message it sends to Actor B in order to see if A is properly processing it's data and sending the right message to B. How would one test this? It took me a long time to get this cooked up on my own...but it does seem to mostly work.
class A extends Actor { ... }
class B extends Actor { ... }
class C(p: TestProbe) extends B {
override def receive = {
LoggingReceive {
case x =>
println(x.toString)
p.ref ! x
}
}
}
case class MsgToB(...)
// Spec class which extends TestKit
"A" should {
"send the right message to B" {
val p = TestProbe()
val a = TestActorRef[A]
val c = TestActorRef(Props(new C(p)))
// Assume A has a reference to C. Not shown here.
a ! msg
// Assert messages
p.expectMsgType[MsgToB]
}
}
Is this the best means of doing this? Is there a better practice?
To me it sounds like what you want is to test the behaviour of actor A in isolation. In order to do this, you need to be able to control how actor A gets its reference to actor B. For example, you could provide the reference in the actor's constructor:
import akka.actor.{Actor, ActorRef, Props}
class A(refToB: ActorRef) extends Actor { ... }
object A {
def props(refToB: ActorRef): Props = Props(new A(refToB))
}
There are alternative ways you can pass the reference to actor B to actor A, but using the constructor is arguably the easiest choice. In the example above, we also provide a method for creating the correct Props for the actor.
Now that you can control the reference to actor B, you can replace the actor reference with test probe in tests.
import akka.testkit.TestProbe
// Initialise a test probe
val probe = TestProbe()
// Actor A with reference to actor B replaced with the test probe
val a = system.actorOf(A.props(probe.ref))
// Send a message to actor A
a ! someMessage
// Verify that the probe received a correct response from actor A
p.expectMsgType[MsgToB]
Notice that I created the actor using the actor system from the TestKit instead of using the TestActorRef. This means that the actor message processing will be asynchronous instead of synchronous. Personally, I've found the asynchronous testing style to be a better fit because it better represents how the actor is run in a production system. Asynchronous testing is also recommended in the official documentation.
Just writing a unit test to ensure an actor shuts down under certain conditions, so I have a test like:
val tddTestActor = TestActorRef[MyActor](Props(classOf[MyActor], "param1"))
tddTestActor ! someMessage
tddTestActor.isTerminated shouldBe true
I'm picking up a warning that isTerminated is deprecated. The hint recommends I use context.watch() however in a unit test I don't have a parent actor or any context to watch.
What would be the bext way to validate tddTestActor shuts down ?
I agree that watching is the best way to get this done. When I am testing for stop behavior, I will usually use a TestProbe as the watcher to check on my actor under test. Say I had a very simple Actor defined as follows:
class ActorToTest extends Actor{
def receive = {
case "foo" =>
sender() ! "bar"
context stop self
}
}
Then, using specs2 in combination with akka's TestKit I could test the stop behavior like so:
class StopTest extends TestKit(ActorSystem()) with SpecificationLike with ImplicitSender{
trait scoping extends Scope {
val watcher = TestProbe()
val actor = TestActorRef[ActorToTest]
watcher.watch(actor)
}
"Sending the test actor a foo message" should{
"respond with 'bar' and then stop" in new scoping{
actor ! "foo"
expectMsg("bar")
watcher.expectTerminated(actor)
}
}
}
I'm using Spray in my application and from the examples I've see on Github it looks like people handle HTTP requests in Akka by passing the HTTPContext object around to all the actors and calling onComplete { } on the Future in the last actor.
Is sending the context deep down in the application really a good idea ? This way every event object will have a context parameter.
How do we handle HTTP requests & response properly in Akka? I've read this article but I would like to know people's thoughts who run Akka in production on the right way of achieving this.
I prefer to use the ask pattern in the Spray service, and the onSuccess directive, e.g.:
trait MyService extends HttpService {
def worker: ActorRef
implicit def timeout:Timeout
implicit def ec:ExecutionContext
def askWorker: Future[String] = (worker ? "Hello").mapTo[String]
def myRoute = path("/") {
get {
onSuccess(askWorker){
case str => complete(str)
}
}
}
}
Then a concrete actor such as:
class ServiceActor extends MyService with Actor {
implicit val ec = context.system
implicit val timeout = Timeout(3 seconds)
val worker = context.actorOf(Props[WorkerActor])
override def actorRefFactory = context.system
def receive = runRoute(myRoute)
}
I like this pattern rather than passing the request context around since it means that the other actors don't have to have any concept of Http. The service could be completely replaced with a different protocol. In this example the worker actor is can be something like:
class WorkerActor extends Actor {
def receive = {
case "Hello" => sender() ! "Hello World"
}
}