How to map an xstate-test event that is meant to be "emitted internally"

[CMCDragonkai]

I have an event in a state machine that isn't meant to be triggered from outside of the state machine. This event is triggered upon completion of some asynchronous process inside the state machine.

So the state machine goes into a state called backingUp. This process can involve some time. When it completes, a BACKUP_FINISH event/transition occurs which means the state machines goes to another state.

In xstate test, we have something like:

BACKUP_FINISH: {
  exec: async (backupRestoreService) => {
    // what to do here?
  }
}

There are no calls that we need to do here. Once in the backingUp state, the process runs and completes, it will automatically transition to the next state.

Our original way of doing this was to add some sort of monitor, so that way the exec handler just blocks until the backingUp completes. Is this correct?

[CMCDragonkai]

After thinking about this a bit more. It seems xstate-test was designed to test transitions and states that are observable by something external to the service/implementation. If the model we have is modelling internal transitions and states that are not observable by external parties, then xstate-test cannot know how to generate paths for them nor know when to actually run the test assertions. This makes it bit tricky to use on models that were designed to explain how a system implementation internally works.

[Andarist]

Isn't what a machine do always observable in some way? I mean - it might not be easy because u might need to mock some global stuff or whatever, but the logic that machine handles usually has to be observable in one way or another. Otherwise, you could just remove parts of it and nothing would change.

[CMCDragonkai]

I was trying to use a state machine to model things that are not observable from outside the implementation.... but it turns out to do model based testing, you do have to observe it. Basically ideally the xstate-test has some way of breaking encapsulation. But it's not that easy. Especially when the non-observable behaviour is both asynchronous (order of operations is not guaranteed) and transient (the states only exist for a short amount of time).