Constraining expectations using states - possible bug?

[Alex Bradley]

Hi,

I am mocking an object that dispatches changes events when a property changes - when a change event is dispatched, I want to ensure that the requested value of the property is the newly changed value, as this is behaviour that the observer expects.

Overriding expectations does not appear to work (I've caught brief discussions on philosophical pros and cons of this in the past). Instead, I've tried to represent this using states e.g.:

            var propertyStates:States = states('property').startsAs('propValue1');
            stub( myMock).getter("propertyValue").returns("propValue1").when( propertyStates.isStateOf('propValue1'));
            stub( myMock).getter("propertyValue").returns("propValue2").when( propertyStates.isStateOf('propValue2'));
            stub( myMock).asEventDispatcher( );

            trace( myMock.propValue); // Expect to see propertyValue1
            propertyStates.become( 'propValue2');
            myMock.dispatchEvent( new ChangeEvent( myMock));

            trace( myMock.propValue); // Expect to see propertyValue2           

Unfortunately, both of the trace statements above will return null.

There appears to be a bug in the version of StateMachineState that is returned from the StateMachine when calling isStateOf() method (during setup of the Expectation):

               public function StateMachineState(stateMachine:StateMachine, name:String)

                {

                        _stateMachine = stateMachine;

                }

 

From above, you can see that the name of the state is not stored intermally in the state. This means that subsequent methods activate() and isActive() can never be true.

Is this correct? If I could get state-specific behaviour it would be an enormous help in writing certain tests I need that require mutable mock values.

Cheers,

Alex