spike: model-based testing of data entry forms with xstate

[jschuurk-kr]

Scope

This is a research spike into model-based testing of data entry forms with xstate. For a visualization of the model, copy the machine into https://stately.ai/viz.

The idea behind model-based testing is that you describe a model (e.g. of our data entry form) in code and then generate test cases based on a path algorithm. Xstate supports both shortest and simplest path. I chose simplest path because it gives more coverage.

The purpose of this PR is to decide if we see value in this kind of tests for data entry. If we decide we want to proceed with these model-based tests, we should discuss which states we want to include in the model. The current model results in 23 tests, but it's not complete. Entering data that results in an error or a warning, is still missing for example.
We should then also decide if these tests should remain separate Playwright tests. For the spike that seemed the best choice.

How to run

Xstate generates 23 tests that run sequentially, because PR #831 is not part of this PR. So best to run for a single browser with either npm run e2e:model -- --project chrome or npm run e2e:model-dev -- --project chrome.

Review questions

• Do you see value in this kind of testing for data entry?
• Should the model contain more states, e.g. input that results in an error or warning?
• Should the model contain fewer states, because it's already too complicated?
• Is there anything else you like or dislike about this kind of tests?

[oliver3]

I think it is worth further investigating if it can augment or replace "manually crafted" paths through the data entry.

I was wondering if child states for pages or modals would be possible, to make them more "self-contained" and will prevent this one model to expand very quickly. Maybe the history can remember the cache so that it also does not cause duplication of states? But I'm not sure if I understood this correctly..