I've also ran into these scenarios and have written a set of unit test patterns (and supporting classes) for Akka testing gotchas like
- Guidelines on how to test an actor in isolation from other actors - Testing that an actor's child actor received a message without actually creating the child actor - Test an actor by using its Path without having to create all it's parent actors - Testing functions that send messages to an Akka actor without having to actually run the actor being called The write up is located here: https://gist.github.com/jconwell/8153535 Its basically a set of actor classes that act as proxy/mock actors for different scenarios Hope this helps, Turbo On Tuesday, October 1, 2013 3:23:31 AM UTC-7, paweł kamiński wrote: > > got it:-) this is preferable way of doing things. anyway just quickly > overriding my Publisher in test I ve found that akka requires actor > (PublisherTestable) class to be public class but maybe it is my mistake. > > continuing the abstract discussion: > I can imagine that akka system would work in test mode and you could just > use semi mocking api. > I understand it is not available now and it would be hard to extend > current test kit. > > api could be something like > > TestActorRef.stub(anyDummyActorRef).onCreate(Worker.class) > TestActorRef.answer(new Object()).onReceive(Work.class) // this is not > really a problem but maybe sometimes would be nice to have such > functionality > > and then > final Props props = Props.create(Publisher.class); > final TestActorRef<Publisher> ref = TestActorRef.create(system, props, > "testA"); > > this would simplify unit testing, of course I can do only integration test > but I prefer to have many, fast, isolated unit tests. > > is this realistic to extend TestKit? can I help extending it? > or do you think is just a bad idea to do so, as there are consequences I > dont fully understand now. is it bad idea because scala api handles such > cases in elegant way and it is no use investing any time into java API? > > thanks for keeping this conversation active event I may ask stupid question > > > On Monday, 30 September 2013 21:52:23 UTC+2, Björn Antonsson wrote: >> >> Hi Paweł, >> >> On Monday, 30 September 2013 at 20:48, paweł kamiński wrote: >> >> I was thinking about your answer a bit longer:-) >> >> I cannot imagine overriding creating actor functionality just for >> testing. akka is all about creating actors ;-) >> in my case I need to create at least 2-3 types of actors so I going >> introduce a lot of code in test just to test one actor. >> >> I would like to have something to order akka system to create probe/dummy >> actor for given actor types (so in general a captor), let akka return ref >> for probe/dummy every time my code call actor creation and then I could >> verify that my actor (under test) had this and that interaction with a >> probe (return array of messages in mailbox). >> >> given all this we could maybe instruct akka system to return message if >> message of type arrive - but usually I try to send fire-forget messages and >> I do not g-a-s. >> >> Am I crazy ? :-) is this hard to get? who can I talk to? :-) >> >> >> Solving this in a generic automagic way for all cases is not really >> practical. How would the system know which stub to create and how would the >> stub know what to answer if there is an interaction? >> >> You can inspect messages and interactions by using the test probes in >> TestKit http://doc.akka.io/docs/akka/2.2.1/java/testing.html >> You can also let the Probe forward messages and even install an AutoPilot >> in a Probe that sits between two actors and forwards/replies to messages. >> >> Another way would be to factor out all the code that you can't run in the >> Worker (like HTTP requests and such) into methods, and in your test just >> subclass the Worker and stub out those methods. >> >> Anyway, you still have to factor out the Worker props or creation logic >> in some way to be able to inject other actors. >> >> B/ >> >> On Sunday, 29 September 2013 19:52:23 UTC+2, paweł kamiński wrote: >> >> I was worried you suggest something like that :/ >> >> fair enough, thanks for answering >> >> On Friday, 27 September 2013 23:41:11 UTC+2, Akka Team wrote: >> >> Hi Paweł, >> >> the easiest way is to factor the creation of the Worker props out into a >> method within the Publisher so that in the test you can override that to >> create a dummy actor. >> >> Regards, >> >> Roland >> >> On Wednesday, September 25, 2013, paweł kamiński wrote: >> >> Hi all, I am starting with akka and I really cannot find any answer what >> is the right way for testing parent - children messaging. >> >> Im using Java API. My parent actor looks like this >> >> public class Publisher extends UntypedActor >> { >> public void onReceive(Object message) throws Exception >> { >> if (is(message, PublishingRequest.class)) >> { >> // cast message >> getContext().actorOf(Props.create(Worker.class), >> "worker").tell(new Work(message.getId()), getSelf()); >> >> // do other stuff >> } >> else >> { >> unhandled(message); >> } >> } >> } >> >> and child actor >> >> public class Worker extends UntypedActor >> { >> public void onReceive(Object message) throws Exception >> { >> if (is(message, Work.class)) >> { >> // cast message >> // do Async GET call to other system and replay to parent >> doAsyncGet(message, getSender()); >> >> // do other stuff >> } >> else >> { >> unhandled(message); >> } >> } >> } >> >> when creating Publisher with TestActorRef and sending PublishingRequestto >> it, Publisher >> try to create Worker actor and send message to it. >> The test will fail as Worker cannot send any messages over HTTP. can I >> somehow intercept actor creation and stub worker with something useful for >> testing purposes??? >> >> I really want to test that Publisher created (code for that was executed) >> Worker and proceed to test businesses login of the Publisher (the other >> stuff) >> >> thanks! >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> -- >> Akka Team >> Typesafe - The software stack for applications that scale >> Blog: letitcrash.com >> Twitter: @akkateam >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- >> Björn Antonsson >> Typesafe <http://typesafe.com/> – Reactive Apps on the JVM >> twitter: @bantonsson <http://twitter.com/#!/bantonsson> >> >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
