Semantics and BDD


While being aware of state machines this is my first real look at it. Given the point of a state chart is to model something (in my case software) my perspective is: how can I use this to model something and also translate that into testable outcomes. I am also exploring microservices as a front end architecture where each service has its own state and is ignorant of all other services. Inter-service communication is via messages (the details of which don’t matter here).

So, I am thinking about an example of a context / popup menu service which I made a simple chart for here:

In other design modalities, the usual way to talk about message / event emitting is that it just happens - fire event “menu-item-clicked” and pass the relevant data. I am trying to get my head around the way to represent that in a state chart. (In the app the message would actually be more like “user-wants-to-do-X” so the service that knows about X would accept that message but here I will stay with the more traditional description).

I have drawn the part of the process that emits the message “Menu item X was clicked” to the world as a “state” but is that true? Is it true to say the menu is in the state of “sending a message” or that sending a message is just an event that happens within the menu we are modelling?

If the menu is in the “sending a message” state then the chart seems reasonable. If that is not a genuine “state” as such then does there need to be some way to code “actions” like that into the chart?

I know this might seem like semantics but I am attempting to map this to the Behaviour Driven Development pattern when I am using Gherkin to describe the app’s logic. eg
Given {some state}
When {some transition}
Then {test if we are in the desired new state or not}

Part of that testing would be whether or not the “menu item X was clicked” message was emitted. So, I guess it might translate as:
Given the “Showing” state
When the user clicks a menu item
Then we should be in the “sending message” state
And that message should look like {some pattern}
And the menu state should now be “Hidden”

I would appreciate any thoughts on how others have approached this translation of state charts into testable outcomes and the language of that pattern.

Thanks so much for a really interesting realm.


This is shedding some light:


And this:


Have you read Harel’s original papers? It’s on the FAQ section of the landing page and touches on some of these questions. See also Samek’s crash course in UML state machines PDF


Thanks Kevin. No, I haven’t read those yet, but I will. I find this an interesting topic. I learned a lot from reading the info on the xstate package.

Thanks again for responding,