Re: [akka-user] Unit test for Persistent Actor Replay

Yup, and you don't need the null check, it will retry for any exception, which here will be thrown by actorOf fre 2 dec. 2016 kl. 21:17 skrev Richard Rodseth : > Thank you! I was not aware of awaitAssert. I think the following should do > the trick. > >

Re: [akka-user] Unit test for Persistent Actor Replay

Thank you! I was not aware of awaitAssert. I think the following should do the trick. watch(definitionReader) system.stop(definitionReader) expectTerminated(definitionReader) var definitionReader2: ActorRef = null awaitAssert { definitionReader2 = system.actorOf(actorProps, actorName)

Re: [akka-user] Unit test for Persistent Actor Replay

For testing purposes you might need to optionally override that way of defining the persistenceId by passing it in as constructor parameter. Another way is to retry the actorOf in the test until it is successful. awaitAssert in testkit can be useful for that. fre 2 dec. 2016 kl. 20:16 skrev

Re: [akka-user] Unit test for Persistent Actor Replay

I see now that https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala works by generating a unique id in beforeEach(). But I wonder how all your customers test recovery of their persistent sharded entities when they follow your

Re: [akka-user] Unit test for Persistent Actor Replay

I wondered about that, but the persistence id is derived from the name (it's an aggregate root) override val persistenceId: String = "XYZ-" + self.path.name On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall wrote: > You can start the second actor with a different

Re: [akka-user] Unit test for Persistent Actor Replay

You can start the second actor with a different actor name but with the same persistenceId. If you don't specify the actor name a unique name will be used. /Patrik fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth : > I'm also looking here: > >

Re: [akka-user] Unit test for Persistent Actor Replay

I'm also looking here: https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala There's a lot of inherited code in these tests, and it's unclear to me how the issue is avoided here: abstract class PersistentActorSpec(config: Config)

Re: [akka-user] Unit test for Persistent Actor Replay

I see that TestActorRef is not an option with PersistentActor http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef This is not the clearest paragraph, but perhaps provides an option: "It may also be required during testing, when the test subject

Re: [akka-user] Unit test for Persistent Actor Replay

Well, it is solved in Akka Typed: removing system.actorOf() and system.stop() is the only way to "solve" this. The reason is that the semantics of these methods are incompatible with the distributed nature of the ActorSystem. Regards, Roland Sent from my iPhone > On 2 Dec 2016, at 08:12,

Re: [akka-user] Unit test for Persistent Actor Replay

Good question! The notification of its death hadn't reached the closest of kin (its parent) so they hadn't even put it in the ground when you proposed to create a new one and call it the same thing, so they (rightfully so) objected to that suggestion. This trips people up every now and then, but

[akka-user] Unit test for Persistent Actor Replay

We have a unit test for a persistent actor, which instantiates a second instance after waiting for termination of the first. watch(definitionReader) system.stop(definitionReader) expectTerminated(definitionReader) val notificationDefinitionReader2 = system.actorOf(actorProps, actorName) This