The other thread on FSMs got some interesting stuff in it so I thought i re-frame this question i sent the day before:
Would it be useful to derive the FSM chart for a clojurescript app based on logging of user actions and state transitions? Would a visual FSM that is auto-generated from such logging, e.g. during automated UI testing, be helpful in documenting how the app works and maybe in visual debugging? I think that going the other way around, i.e. generating clojurescript code from FSM charts built manually (as Ruslan's vFSM does) is equally an educational exercise but I am wondering if there is more real world practical benefit in going the other way: generating the FSM charts from code (from automated UI tests where both user actions and state transitions are logged) After all, FSMs and FSM based CASE tools existed for decades but have not managed to gain any popularity. So maybe generating FSM charts from actual hand written code would be more valuable as a program comprehension/documentation tool? Here is why code generation from FSM charts can at most be a purely educational exercise. This guy captures it well: http://www.skorks.com/2011/09/why-developers-never-use-state-machines/ Going the other way around (FSM from code execution) seems to offer the debugging and visualization benefits without the hairy mess. Marc Sent from my iPhone > On May 8, 2015, at 1:58 PM, Marc Fawzi <[email protected]> wrote: > > Assuming an entirely app-state-driven UI (i.e. UI simply reacts to changes in > app state and is never controlled directly by the application logic) , > > Has anyone tried to test their app by testing against an input/output spec > that maps each UI event to a set of changes in the app-state atom, and > running assertions on that? > > With JS, we can overwrite addEventListener before it's used by the app and > this way we'll know when any UI event is triggered, without having to inject > any debugging code into the handlers. All I would have to do is to have a > map that links each UI event on a given element (or the window object) to a > set of mutations in the atom and then assert that the expected mutations have > happened. > > This would catch many errors stemming from failure to update state correctly > in response to UI events. > > Is there a formal approach around this? and is it a good idea in the first > place? > > Thanks in advance > > > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
