I mostly agree with you and the NamedStateBehavior may only be useful when you have well defined state transitions (low change frequency) or not useful at all but the point is it I could write it and decide if it was useful if Behavour supported being extensible. I can't see how I could do that with the current implementation. Tomorow I might come up with another idea like having a behaviour that acted as a cache for another behavior or ...
On Tuesday, 18 July 2017 21:40:07 UTC+10, rkuhn wrote: > > 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 > <javascript:>>: > > 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). > > > 1. 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.
