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.
On Thursday, November 2, 2017 at 8:48:04 PM UTC+2, Joost den Boer wrote:
>
> 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
>
>
> On Thu, Nov 2, 2017 at 5:28 PM, Alexandr Sova <sovaal...@gmail.com
> <javascript:>> wrote:
>
>> 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?
>>
>>
>> On Monday, March 13, 2017 at 10:58:08 AM UTC+2, Joost den Boer wrote:
>>>
>>> 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
>>>
>> --
>> >>>>>>>>>> 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+...@googlegroups.com <javascript:>.
>> To post to this group, send email to akka...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
>>>>>>>>>> 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.
