How to test Akka Persistence actor

Question

I'm working on a project that's based on Akka Persistent FSM. In particular:

1. I want to know what the best way is to structure test cases for independence? Since state changes are persisted (this is not well explained in the documentation, but can be seen here), it can be tricky to ensure that my persistent actors always begin in a clean state. Is it necessary to build reset into my actor FSM protocol manually? If so, this seems not-ideal, as it's new behavior that require's testing on its own.

2. What's the best way to manage the journal itself in testing? Is there an easy way to configure the use of a different journal for testing, without having to make this selection explicit in the actor design itself? The Plugin TCK section of the docs mentions deleting the whole journal file manually. This seems reasonable for testing plugins themselves, but seems like an unnecessarily low-level solution for application code. Perhaps I need to explicitly call through to the journal's asyncDeleteMessagesTo in test tear down? This still seems pretty low-level, but perhaps it's just infrastructure that hasn't been built into the library yet.

Statist

Answer 1

When unit testing persistent actors, you can use an in-memory persistence plugin, e.g. https://github.com/dnvriend/akka-persistence-inmemory

No code changes are required, you can simply use a different application.conf in src/test/resources than in src/main/resources.

For independence between Unit tests, you can make the persistenceId something which is injected into the actor. Create a new instance of your actor with a different persistence Id for each test. Then, even if events from previous tests still exist in memory, they will not effect subsequent tests.

If you use Akka testkit, a new actor system will be created per test run, and at the end of the run when the system is shutdown, the contents of the inmemory journal are destroyed so no manual cleanup required.

Afteryears

Very informative -- I will proceed with this method. Will I have to duplicate everything from my main application.conf, or can I simply provide the overrides? At the moment, journal configuration is all I'm doing, but I wondering in advance for when I eventually add more configuration. I don't love the concept of injecting the persistenceId, but if that's the best I can do, that's the way to go then. – Statist

@Afteryears can you please post an exemple with no manual need of journal cleanup? is it handled by the inmemory plugin ? – Stackhouse

@Stackhouse it's in the nature of it being In Memory. Once the process dies the memory of that process does not persist. – Afteryears

can you post for me some advantageous Links about this ? – Stackhouse