Gherkin scripts are a great way to represent test cases. Essentially, you describe features, each of which has a set of scenarios to test, each of which consists of a set of steps. The steps follow the pattern: "Given some state of the system, When the user does x, Then the user should see y."
While this is a helpful pattern when running the tests, the number of Gherkin test cases (scenarios) scales with the number of paths through your system, which means that managing them can quickly grow out of hand.
We can use the power of the declarative nature of statecharts to generate test scripts based on a much smaller, simpler, and easier to maintain statechart. Statecharts describe the states of your system, the set of possible events in each state, and (potentially guarded) transitions to take when those events occur. Test cases then correspond to paths through the statechart. Given the user is in state x, When the user does y, Then the user should see whatever UI corresponds to state z.
By generating test scripts from statecharts, you only need to do work proportional to the number of states and xstate-to-gherkin takes care of doing the much larger work proportional to the number of paths through those states.
Here's a codesandbox demo using the library: