These are chat archives for akkadotnet/akka.net

2nd
Aug 2018
Shukhrat Nekbaev
@snekbaev
Aug 02 2018 08:25
what is the recommended approach to mocking child actors, say, I have actor X which internally creates A and B. I'd like to test only X and would like to substitute A and B with test probes and probably autopilot(?). However, because X does Context.ActorOf it doesn't seem possible, unless, of course, there's way to hook into some Context.ActorOf test callback if one exists. Another approach I've found is to pass a dependency into X which is responsible for creating children and substitute it when testing. Or... maybe just extend the static Props actor creator for X and make it receive a lambda which takes in the Context
Arsene Tochemey GANDOTE
@Tochemey
Aug 02 2018 08:39
Hello
How can I best load test my actors?
Stijn Herreman
@stijnherreman
Aug 02 2018 09:28
I'm considering rewriting my unit tests for an FSM because they often unnecessarily break when changing implementation details of the FSM. https://www.planetgeek.ch/2011/05/17/how-to-unit-test-finite-state-machines/ advises against calling a method like SetState in the unit test, and advises testing for side-effects external from the FSM. That certainly sounds like it could reduce test breakage. Anyone here experienced with testing FSMs? What do you recommend?
Bartosz Sypytkowski
@Horusiath
Aug 02 2018 10:47
@snekbaev actors can promote a bit different approach to unit testing. Since a single application feature can be result of work of multiple actors, testing them in isolation sometimes just doesn't make sense. Actors work together in systems, and sometimes it's best to test them as such.
@stijnherreman from my experience in any message based system the best way of working is to have a collection of inputs that you wan to test (they also are responsible for moving state machine to a desired state) and then just assert outputs and side effect. In practice internal state and implementation doesn't really matter as long as FSM reacts with world around it as designed.
Bartosz Sypytkowski
@Horusiath
Aug 02 2018 10:53
@Tochemey what do you mean by that? There are plenty of ways to perform load tests, but everything starts with what is this test supposed to answer?
Shukhrat Nekbaev
@snekbaev
Aug 02 2018 11:06
@Horusiath I've test covered the child actors individually (they don't have their own children), but I'd like to test the orchestration logic for their parent, for example, that it stashes correctly, takes certain actions depending on what children reply. Of course I could leave as is, but in this case will have to mock a lot of things and I don't really feel like I need to do that in this specific case. What I'm trying to do now: I created a nested class for the parent which inherits in interface for creation of Props for A and B. Then I added one more static Props methods in to X for its own creation, one overload takes IChildCreator. Now I'm trying to mock this interface and return a test probe with autopilot and see it this even works :)
Shukhrat Nekbaev
@snekbaev
Aug 02 2018 11:30
heh, it seems to work, but will test further. If somebody needs to pass a probe and return Props - a dummy wrapper seems to do the trick (found online):
public sealed class TestProbeWrapper : UntypedActor
        {
            private readonly IActorRef _target;

            public TestProbeWrapper(IActorRef target)
            {
                _target = target ?? throw new ArgumentNullException( nameof( target ) );
            }

            protected override void OnReceive( object message )
            {
                _target.Forward( message );
            }
        }
Props.Create( () => new TestProbeWrapper( getActorProbe ) )
Vasily Kirichenko
@vasily-kirichenko
Aug 02 2018 13:29

@Horusiath what is a more typed way to make an Ask?

let loop (ctx: Actor<Msg>) (state: State) = function
    | GetConfiguration ->
         ctx.Sender() <! (Ok state.Configuration : Result<Configuration, string>)
         ignored()

here if I remove the type hint it's inferred as Result<Configuration, obj> which results with disasters.
It's an entry point to the actor system, so I cannot pass an IActorRef<>.

Bartosz Sypytkowski
@Horusiath
Aug 02 2018 17:30
@vasily-kirichenko popular option is to use replyTo pattern (add a field to a message, usually called ReplyTo), which contains an actor to which you may want respond to. Then in code instead of sending reply to Sender, send it to msg.ReplyTo. This could work with ask via Ask overload - tbh. I'm not sure if this method is already published.
Jay DeBoer
@jaydeboer
Aug 02 2018 19:19
Is it possible to have an actor not restart its children when it encounters an exception and restarts?