Hi Bryan, thanks for articulating your points! Regarding the first one I’d like to widen the scope of the discussion: is it useful to access the private state of a state machine for testing purposes? I know that I am guilty of creating the akka-testkit nearly seven years ago, allowing precisely that. My own experience and understanding has evolved since then, and it will likely continue evolving in the future, so take my learnings with a grain of salt.
My current take on this topic is that tests that access the internal state of a state machine (or any kind of component) tend to be too closely coupled to the implementation, to the point of becoming useless. The latter shows when noticing that every change of the implementation requires a matching change to the test suite—but what good is a test suite that just echoes all changes, including the buggy ones? My preference is to formulate tests on the level of expected and externally observable behavior, this has a greater chance of remaining constant across feature additions, refactorings, etc. This is the reason why the focus for Akka Typed tests has been placed on synchronous evaluation with effect capturing, meaning that responses to external stimulus can be observed in a deterministic and efficient fashion. The example of the chat room client list would best be tested by adding clients and then sending a message, followed by checking that all clients (“mocked” by using debugging ActorRefs that just collect incoming messages) received the chatroom communication. This validates a core feature of the chatroom without depending on assumptions regarding the implementation. Regards, Roland > 18 juli 2017 kl. 11:44 skrev Bryan Murphy <br...@murphynet.id.au>: > > OK, I will start it here. The main thing is get the comments and ideas in > front of the Akka developers - if it is has merit you can run with it. > > Overall I like the direction of AkkaTyped but there are a couple of use cases > that I would like to see that seem not supported by the current > implementation (but have become possible with the separation of Behaviour and > Actor). > > Behaviours are like state machines so when testing I would like to send a > message to the behaviour and then verify the resultant behaviour is what I > expect. Ideally a behaviour would have a name (or an identifier with a > generic Identifier type if we want to be more general) and some state data > that we could look at (eg often we keep the same behavior but the internal > state data has been updated eg sessions in the Chat Room example). The > current approach makes the state data opaque because the state become > parameters to a function that creates the behavior so the state is hidden in > the closure. In fact the whole Behaviour is opaque (you can only make > behaviors using the provided factory functions because the interpretation of > behaviors has leaked into every Behavior implementation so it would be unsafe > for users to create their own Behaviors) making it impossible to extend > Behavior to add a name or add State data. For name we could perhaps override > toString but that feels like a hack. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
