Asserting if a particular event was persisted by a persistent actor

[wmeints]

I'm trying to implement a basic event-sourced actor in Akka.NET, and I'm stuck on writing a proper test for it.

My actor receives a command RegisterCustomer and persists CustomerRegistered.
I want my test to verify that the journal received the CustomerRegistered event.

Currently, my test looks like this:

[Fact]
public void CanRegister()
{
    var customerId = Guid.NewGuid();
    var customer = ActorOf(() => new Customer(customerId));

    var invoiceAddress = new Address("Test", "1", "9999 AA", "Test");

    customer.Tell(new RegisterCustomer(
        customerId,
        "FirstName",
        "LastName",
        "test@domain.org",
        invoiceAddress,
        invoiceAddress,
        DateTime.UtcNow));

    // Expect event to be persisted.
}

I couldn't find a method on the TestJournal to verify my expectation. Is there anything I'm missing?

[bauersystems]

I'm sure someone that knows for sure can verify this, but I believe the TestKit has its own version of the ActorSystem that is just for testing. My understanding is that the TestKit is designed to test the logic/behaviour of your actor's code, not the underlying code of the persistent layer. The persistent layer has it's own testing included in it's codebase.

Out of curiosity, why do you want to test the persistence later in your unit tests?

[bauersystems]

The other thing I do is separate the state of a persistent actor out into its own class that only mutates when an event is sent to it. This way, I can build unit tests around the state itself making sure it works correctly, and then testing the actor's behavior separately. I built a StateBase class that will "handle" events similar to how the Receive method works within a ReceiveActor. I have found this approach makes it a lot easier to reason with persistent actors.

If you are interested, I can share with you an example.

[wmeints]

Ah yes, separating the state is a good idea. I've seen that a couple of times in Akka with Scala. I don't really have query messages on my customer class. I use projections to read models for my queries.

[bauersystems]

It doesn't have to be a query message per se. Because an actor is completely encapsulated (in comparison to an object in OO, where you can just reach in and look at the object's state), it becomes more about testing the impact of the functionality. If your message doesn't give a response, then your options for testing impact becomes something along the lines of "what other message can you send to verify the impact?" or "where can you inject a TestProbe to verify a "knock-on" message is being sent out?".

Something to keep in mind is that when you are testing, you have two types of tests you are looking to verify: behavioural & state-mutation. Both are achievable with the impact testing I mentioned, however if you create a state class, you can add a lot more precise unit tests around the state-mutation verification. I'll put together an example project that demonstrates what I mean.

[bauersystems]

Here is the example project that demonstrates the state class I was referring to - https://gitlab.com/andrew.bauer/akka-state-example

As I mentioned previously, I took the concept of how the ReceiveActor works and applied it to a StateBase. It allows you to just raise an event with the state, and the state will handle its own mutation. Keep in mind that to keep this level of encapsulation, you will need to use immutable dictionaries & lists - having a private setter on a dictionary or list doesn't actually make them immutable, it just prevents the property from being re-set (you can still directly mutate them from their methods).

I only had time to create unit tests against the state. The unit tests should demonstrate what I meant by them being more precise for testing the state. For unit testing the actor, it should be simple enough to send three messages to confirm its functionality (ActiveClient, HandleClientMessage, GetClientMessagesQuery); the impact of the first two messages is verified by the result of the third message.

[bauersystems]

Hi @wmeints, if you are using the class I demonstrated within my example, then I have updated it recently. I found that Persist is asynchronous under-the-covers, so if you have behaviour after the Persist that relies on the state-mutation, it won't work correctly. I added the ability to pass in an action that will run after the state-mutation. (I also renamed the StateBase class to ActorState).

[to11mtm]

As one potential work-around (I'll have to refresh on docs to see if there's a more usable answer,) if your persistence plugin has a Persistence.Query plugin, you could use that alongside the Events-By-PersistenceId command to see what you got.

As a more 'general' work-around, I would suggest:

var testProbe = CreateTestProbe();
var persistenceExtension = Persistence.Instance.Apply(actorSystem);

var myJournal = persistenceExtension.JournalFor(journalPluginId);

myJournal.Tell(new ReplayMessages(minSeq,maxSeq, maxReturn, persistenceId, testProbe.Ref));

//wait/fish for your message in testProbe, do needful.

[wmeints]

I added an extra command in the persistent actor to retrieve the current state. I also externalized the state to a separate class to test how applying events changes the state. That enables me to reach 99% coverage. I tried your suggestion, but it's a lot more code, and it's pretty brittle.