We used to do the GUI-bits of our software using Adobe Flash or Flex for many years, but we had our fair share of problems with this.<\/p>\n\n\n\n
Flex was good at creating an attractive and snappy interface well suited for (single) touch-screens, but was cumbersome to develop and maintain.<\/p>\n\n\n\n
Much of the user state and business logic was contained in the Flex layer, which again was tricky to test automatically and debug.<\/p>\n\n\n\n
Now, as\u00a0Flash is slowly dying<\/a>, we decided it was about time to try something different. And the only real option for us was to try doing something with HTML5 and JavaScript, in a so-called\u00a0single-page application.<\/p>\n\n\n\n Typical Web applications rely on gradually building a session, following a given navigational path to end up in a given state. For example, to see what the “My Orders” page looks like, you need to log in and click on the link.\u00a0<\/p>\n\n\n\n You need to have the right state in both client and serve to display the “My Orders” page properly.<\/p>\n\n\n\n This pattern has given us (and probably many others) a lot of headache over the years. Too much state and logic on the client side allows for GUI bugs that are hard to replicate.<\/p>\n\n\n\n Testing and debugging on the client side also tends to be below-par of what we can do with server-side code. Every button clicked in the client typically results in a round-trip to the server, where a state machine is told what the user did, then spits back a new screen for the client to render.<\/p>\n\n\n\n This round-trip may sound slow for a touch screen that should be fast and responsive, but it works well for four reasons:<\/p>\n\n\n\n 1) Server is running on the actual same machine (PC) as a client\/browser So what does one of these screens actually look like? Here\u2019s an example: Pure JSON that represents the entire state needed to display a screen to the user.<\/p>\n\n\n\n This JSON is sent to the browser, it gets run through a generator (Mustache<\/a>) which turns it into HTML, and then we quickly \u201cswap\u201d the new screen into the visible window. After a little styling it up with CSS, it looks like this: It is really great to have this loose coupling between what the user sees, and what the server knows. Let\u2019s see why.<\/p>\n\n\n\n Advantages of this setup?<\/strong><\/p>\n\n\n\n Doing web design without having to click around in the application<\/strong><\/p>\n\n\n\n You don\u2019t have to work the server side into the right state for doing some web design on a particular page. You only need a snippet of JSON (as the one mentioned earlier).<\/p>\n\n\n\n Here I\u2019ll demo our little screen-IDE. It runs on a local little Node Server, and turns JSON into visible screens on the fly:<\/p>\n\n\n\n You can choose from a \u00a0prepared set of JSON examples, or you can copy\/paste in screens from the log files, and then you can adjust the contents by hand to get the condition you want to see.<\/p>\n\n\n\n This provides\u00a0immediate\u00a0feedback to the web designer. After changing CSS (or LESS which we actually use), Mustache-template or JavaScript we only need to refresh the browser to see the latest content. We can also simulate some simple server-side events by passing some JavaScript to Node (look for the Script panel around 0:36 in the video above).<\/p>\n\n\n\n Test the GUI in any way possible<\/strong><\/p>\n\n\n\n Traditionally, there are many disadvantages to test the application using the GUI, but many developers do it anyway because they have no other way to test the GUI, and they can\u2019t run the GUI without the rest of the application.<\/p>\n\n\n\n In our setup, we can for example test that…<\/p>\n\n\n\n * correct screen object is produced by the state machine (pure unit-test) We combine all of these for creating tests with different intentions: we have a lot of the ones closer to the top, and fewer of those further down the list because they are more expensive in terms of resources, and they break easily.<\/p>\n\n\n\n The magic in this mix is that we are able to distinguish between (a) the right content (screens) coming from the server, and (b) the given screen looking correct in the client. This division allows us to keep our tests incredibly fast: The state machines and the screens are exercised by pure unit tests, while various browser tests create screenshots for given screens.<\/p>\n\n\n\n We can also test larger parts of the stack together, or in phases. We do the latter when we generate documentation and screenshots based on our story-tests (but we mock out hardware and remote services):<\/p>\n\n\n\n – Story-tests generate documentation with embedded JSON which will be replaced with real screenshots It\u2019s all incredibly fast, and we don\u2019t have to fire up a real JVM application server – we can just do the screen rendering in the Node simulator.<\/p>\n\n\n\n See exactly what the user saw on-screen at a given time<\/strong><\/p>\n\n\n\n Let’s envision this scenario: Someone delivers a package to a machine, entering the phone number for those who should receive the pickup code on a text message. Then the recipient comes by later, enters the pickup code, and takes their package.:<\/p>\n\n\n\n Since we log most of the things going on in a machine, including the screens that are sent, it should be easy to parse the log file for a sequence of screens that occurred on the machine for a given time, and then play it back again. <\/p>\n\n\n\n So we did just that, and after a few days of development we had created Sherlog:<\/p>\n\n\n\n Not only can we fast-forward and backward through the user\u2019s experience at any pace, we can also copy the screens out of here and then work with them in the simulator if we find a GUI bug or something we want to improve on.<\/p>\n\n\n\n It did not take much code to achieve this: a log parser and a little JavaScript. The neat timeline widget is created using this Timeline<\/a> library.<\/p>\n\n\n\n We can\u2019t see where the user touches the screen yet, but we are working on that too.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.viaboxx.de\/wp-content\/uploads\/2021\/08\/hSAbfAyD-fX6h5gFBL7yFJ_7eIm9udpv7T9KR8EjWvGqRkfwr2udSM8mRNd0gX6mpgs2000-1024x602.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/www.viaboxx.de\/wp-content\/uploads\/2021\/08\/kdE-oLCeLLCG6AHuDuMmxsFX0vr_hbTtwt_fOLPHB0kzCflAddauvw0W4fyLShU7kgs2000-1024x602.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/www.viaboxx.de\/wp-content\/uploads\/2021\/08\/1DEsslgIvpDmavItDXlMJSDKye0NGMT46AyCg2dpR3nK2Cl1wZHPvVZajmKWVLs2VAs2000-1024x602.png\")
<\/figure><\/div>\n\n\n\n
What we have done is to remove virtually all state on the client. All logic is on the server side.<\/p>\n\n\n\n![\"\"](\"https:\/\/lh4.googleusercontent.com\/7XW-X8gZ8JIBRroSlOBhxMiGgxL4GL64rp7kByrsVsMz8sG_2NTPtCPjI1SwOxqmOYFVXgaX-rgRArbzxFjDh-7g6EodcicEP81k4RDZgR9JqX3tnuiW\")
![\"\"](\"https:\/\/www.viaboxx.de\/wp-content\/uploads\/2013\/01\/qczwS2hWWUTJAVrqOO99_detMl3xWPYJm1Kgwi-Bs9IybfAQpIVEph3Mw9WfR0FKOws2000-1024x602.png\")
<\/figure><\/div>\n\n\n\n
The mechanics of the statemachine is also very interesting, but we\u2019ll come back to that in another blog post.<\/p>\n\n\n\n
2) We use\u00a0WebSockets, so events from the server have an immediate effect on the client.
3) Some smart caching and JavaScript to update the page quickly.
4) We have very simple screens with small payloads.<\/p>\n\n\n\n
<\/p>\n\n\n\n[codesyntax lang=\"javascript\"]\n\"decision\": {\n\"def\": {\n\"headline\": \"Please decide\",\n\"question\": \"Is yellow more green than blue?\",\n\"type\": \"decision\"\n\"events\": [\n{\n\"id\": \"yes\",\n\"text\": \"Yes\"\n},\n{\n\"id\": \"no\",\n\"text\": \"No\"\n}\n],\n}\n}\n[\/codesyntax]<\/pre>\n\n\n\n![\"\"](\"https:\/\/lh5.googleusercontent.com\/LvLir2t7YVxbNjmdRUqS2nBWBIRjgiPVfMov8iwJfoJaSoTJz1UtrJaA3F-PHDCc6TFGH34JDE9dKhaiRAmSf98DpCftqRt0MEi_F8pnqbX9IdHBNAN4\")
* expected JSON is produced from the given screen (pure unit-test)
* correct HTML is produced from given JSON (for this we need a browser with a JavaScript runtime, but it can be headless, like\u00a0PhantomJS<\/a>)
* HTML from a screen looks OK (taking screenshots using PhantomJS)
* HTML from a screen looks just right (this requires the use of a production browser on the production operating system, and taking screenshots with\u00a0Selenium\/WebDriver<\/a>)<\/p>\n\n\n\n
– The documentation is piped through a script, where the JSON is rendered into real screenshots<\/p>\n\n\n\n