Hi Lawrence,
you don’t need to pass around ActorContext: just return the Props to the actor
and call context.actorOf() there. Passing around ActorContext is not something
that should be handled with caution, it is a recipe for disaster and will
result in weird failures eventually; the reason
Hi Roland,
Yes that makes sense, especially since the class is effectively an actor :)
Does the same rule apply with code that just performs some behaviour on
behalf of an actor? I.e. code that doesn't actually represent an actor in
its own right?
In my example, I have isolated the 'chatter'
Using TestActorRef on implementations of Processor (and
EventsourcedProcessor) appears to introduce a deadlock at the point of
calling into the snapshot store actor.
The result is an actor-under-test that never completes recovery.
I have worked-around this issue by providing
Hello Lawrence,
Because of the processor’s inner workings (how it interacts with the
Journal) it does not make sense to test it using the *synchronous* test
utilities (such as TestActorRef).
Please do not use TestActorRef with Akka-Persistence - use the plain
TestKit and it’s probes and other
Hi Konrad,
I'm currently using TestActorRef to obtain the underlying ActorContext. I
am using this to assert the actor is passing its own context as an argument
to a mocked-out dependency.
Can you think of another way using existing TestKit probes, or is this the
best way?
Thanks,
Lawrence
We strongly advertise against exposing your ActorContext - it's scary what
could happen with it being accessed from outside of the respective actor.
What's your use case? Perhaps there is a better way to test / abstract it?
On Wed, May 28, 2014 at 4:56 PM, Lawrence Wagerfield
I had an Actor whose code grew to be quite large, so this is the result of
a refactoring.
The new class performs actions on behalf of the actor, impersonating it, so
to speak. It caries out various send operations, sets up state with
un/become, etc.
The refactor produces clearer and more
