ursenzler
commented
6 years ago Hi Paul,
If possible, I'd test for the side effects that the state machine executes with its actions - not the internal state. This gives you better easier refactoring possibilities because the tests are not coupled to the internal states of the state machine.
A second option is to externalise some states (providing a property on the class containing the state machine that you can check for. This makes sense if your production code needs to know about some states. This decoupling of internal and external states again helps later refactoring.
If your tests would become much easier - despite the coupling of production and test code - then you can use an extension like I use it in the tests of the state machine. You find an example here: The code of the extension providing access to the current state: https://github.com/appccelerate/statemachine/blob/master/source/Appccelerate.StateMachine.Specs/Sync/CurrentStateExtension.cs A sample usage: https://github.com/appccelerate/statemachine/blob/437c7de9c2756b1092b4f447322ec5b39257658b/source/Appccelerate.StateMachine.Specs/Sync/Transitions.cs#L45
Let me know if this helps, Urs
I'm new to the appccelerate state machine library and am impressed with its interface and features, especially in support of hierarchical state machines.
I have a couple of questions:
1) How do I determine the currently active state, other than through OnEntry methods or handling the TransactionCompleted event? Is there a function available to return the current state?
2) In the case of a hierarchical state machine, is there a way to get a list of the currently active states, or, alternatively, a way to determine if a specified state is active, e.g., a IsActive(state) boolean function?
In general, I'm looking for ways to programmatically determine the internal state of my state machine as I develop/test my code. This helps verify that my state machine's behavior matches its configuration.
Thanks,
Paul