UnitTesting for Akka.net Actors

Question

I am trying out Akka.net. So far I just created a simple HelloWorld-style application. Usually I am using TDD approach in my development but with Akka.net I don't know where to start with my unit testing.

After some googling I realized that original Java/Scala Akka framework uses a dedicated module akka-testkit which is seems to be unavailable in the .Net port.

Is anybody (especially guys from markedup.com) found a way to do unit testing for actors?

Mitzimitzie

Answer 1

[Edit] There is now a more complete and better post on how to do unit testing with Akka.NET here https://petabridge.com/blog/how-to-unit-test-akkadotnet-actors-akka-testkit/

[Old] Akka.Testkit have been ported and we aim to publish it on Nuget very soon. If you want to try it out already, you have to download the source from https://github.com/akkadotnet/akka.net

The best way to get started would be to check out our own unit tests inside Akka.NET. There are specs ported from JVM using Akka.Testkit, that should give some good examples on how to test actor systems.

For example see: https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka.Tests/Actor/ActorLifeCycleSpec.cs#L116

Potentilla

Answer 2

I'm currently working on docs for the TestKit (should be live next week) but in the interim, I'd suggest checking out this thorough intro to the TestKit. It covers the core and advanced API features including how to test various hiearchy patterns, async calls, virtual time, scheduled messages, etc. (disclosure: I wrote it).

Stomachache

Answer 3

I've been developing a trading platform utilizing Akka.NET, my test suite is written with the xUnit2 framework and implementing the Akka.NET TeskKit.

Akka.TestKit is used as the base class which allows you to instantiate Sys.ActorOf. This is effectively a fake ActorSystem as per the links, I'm creating a fake CommandBus (example at the bottom of the post), a very small ReceiveActor which simply captures any messages sent by the SignalProcessorExit class under test (which is simulated by the TestActor which sends any messages back to itself). The contents of the message can then be examined to test the actors behavior (so I'm not peeking inside the actual actor itself, merely verifying its behavior). I found this counter intuitive initially but once you get used to how the TestActor works things get simpler.

The constructor is generating a Fresh Fixture for each test which includes tearing down and rebuilding the Sys.ActorOf test ActorSystem.

I'm using ExpectNoMsg() and ExpectMsg(T) here to grab the message received by the TestActor and make assertions based on it.

Mediaeval

Answer 4

Using the TestKit seems to be the recommended and 'official' practice. But you can only test the actor in its full behavior, as part of a 'fake' system (the test system).

I might be resisting that only because I am starting with actors, but that doesn't feel right to me. I want/need to unit test my actor's methods individually, not as part of a system.

So what I have been doing so far is taking away the logic part of the actor and the state in another class that I can unit test at will, and having an instance of that class in the real akka actor. You can even map and methods properties if you want to abstract that away.

I have seen this recommended here for akka on Scala: How to test a public method in an akka actor?, but it applies to akka.net.

While testing the actor as part of a system makes sense, my unit testing requirements conflict with that.

My example: I was creating an actor that received data from a network call, and updated the UI if that data changed in specific ways. Now the common approach to test the data processing with TestKit would need me to either make the actor answer the message with his new data (not my intention at first), or make multiple calls for each change scenario - and then data processing would be tested in conjunction with state comparison. I don't like either changing the behavior just to allow testing nor testing 2 or more different parts of the actor.

So I did as I explained, extracted a logic class that handles each message type in a different method. I can test data processing, I can change the state and test the state comparison methods. Much cleaner that way.

Finally, if you are playing around with akka, you do need to use TestKit. You'll want to test the actor's full behavior. But I still need more granular testing, and wonder why it's not possible to new up actors to do just that (though I get it should NEVER be done out of testing context).

Lederman