Transform user actions into test cases
~Elm Architecture: step
~Elm Architecture: event handlers
Testing the ~Elm Architecture
- The app is a composition of functions
- Data flow can be recorded during user sessions
- The functions can be tested through invariants
- Only views can be tested
- Recorded data takes lots of space in disk unless a diffing mechanism is used (e.g., tx-data)
- Can reproduce the original States with step, so views and update can be tested.
- If the step function introduces randomness, the reproduced State diverges from the original State, leading to spurious errors.
- Everything can be tested: event handlers, step, views.
- Need to monkey patch React's Event Dispatcher.
- Same randomness problems as with Actions and more.
Test User Sessions Demo
Playback Sessions Demo
SauceLabs Playback Sessions
Problems: Too much data
- Is it possible to use all user sessions in each test run?
- Keep representative samples
- Which samples do you keep?
- Make up a metric and keep sessions that score substantially different for it (e.g., session length, diversity of actions)
- Who runs Facilier?
- Probably you, (like Riemann).
- Does it have to be fast? Can it crash?
- Does it slow your fronted?
- The act of recording and sending sessions over the wire might slow the frontend app down.
- Can the sessions be automatically sanitized?
- Tested logic might depend on data matching the original
- Can the developer sanitize the data by providing a function?
- More work, diminishing returns
- How can the tests access the sanitized data securely?
- Add credentials to the service, harder to setup.
- Does the update function introduce any randomness?
- Random behavior makes the reproduce State diverge from the original one -> errors
- Is the tested logic time dependent?
- original-time vs tested-time might matter.
By Sebastian Bensusan