Contribution to simplify FSM testing?

[Joost den Boer]

Hi,

We are using FSM actors and I was kind of missing handy features in Akka to more easily test these state machines.

What I wanted was a way to verify events are properly handled when FSM is in a certain state, I also want to verify the behaviour of the FSM is all other possible states.

So, to support this more event driven testing, I created a simple DSL which generates ScalaTest cases to verify the handing of an event in all possible states.

In it's simplest version it looks like this:

handleEvent(AnEvent()).inStates(State1, State2).verify { fsm =>
  fsm.stateName should be(State3)
}.otherwiseKeepCurrentState

This tests whether the handling of AnEvent in both State1 and State2 results in a state transition to State3. And in all other states it is expected that the events does not cause a state change.

It is also possible to setup states with a specific data value, or receive not only the fsm actor, but also the event and the start state in the verify function, or do a more comprehensive verification for  the other states:

handleEvent(AnotherEvent(30)).inStatesWithData(Map(
  State1 -> defaultData,
  State2 -> deviceData.copy(progress = Option(20))
)).verifyAll { case (fsm, event, startState) =>
  fsm.stateName should be (DownloadInProgress)
  fsm.stateData.progress.value should be (30)
}.otherwise { case (fsm, event, startState) =>

  // do a more comprehensive verification. E.g. based on the startState.

}

Using this simple DSL, I was able to very quickly define test cases for all events supported by the state machines.

This was very helpful in to then, as a proper TDD developer ;-), implement the FSM actors.

Another 'problem' I encountered while writing test cases for FSM, was that in certain end-states, I want to verify the FSM chanced into the end-state and that actor is also stopped.

With the current TestFSMRef this is not possible, since the 'stateName' and 'stateData' properties are not available anymore after the has stopped.

To overcome this issue, I created a extension of the TestFSMRef which monitors the state transitions of the FSM actor under test. This allows us not only to verify the latest state of the FSM and whether the actor was properly stopped, but this also allows more easy testing of complex FSMs with automatic state transitions since this extension gives access to the full transition log, including the data at each state.

I am more than happy to share these features?

Would this DSL and TestFSMRef extension be a nice addition to the Akka framework?

Any chance this would be accepted it I would make this into a contribution to the Akka framework? Just would like to know whether spending time on that would not be wasted time. 

Regards,

Joost

[Alexandr Sova]

Looks really good. I'm not a framework maintainer, it's just my opinion, but it could be very helpful for me to have such a toolkit. Do you consider to make something similar for PersistentFSM?

[Joost den Boer]

Alexandr,

I'm not familiar with PersistentFSM, but I think it should be possible.

Unfortunately it appears we are the only ones who think this is useful.

Therefore I do not know if I'm going to spend more time on it.

Cheers,

Joost

--
>>>>>>>>>> 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 a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/pmowYVxu0pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Alexandr Sova]

That way maybe it's a good idea to make it a standalone library? Definitely only if you'd have some time to extract such code from your current project and publish it separately.

Because right now I'm testing my FSMs like

"A My FSM implementation" when {

  "at state A" should {

    "be able to do something" in {

      // must matchers here

    }

  }

  "at state B" should {

    "be able to do other thing" in {

      // must matchers here

    }

  }

}

and it's a pain. Specially if state A conflicts with state B what happens always. Hope your solution will make test creation less painful.

To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.