@xstate/test, re-visting states

[UberMouse]

I have a single test model set up for my application that I add to as new functionality is created. This is working out pretty great so far. However, I'm finding in a few places that I want to transition to the same state from multiple places which seems to be impossible as the testing graph will only visit a state once. The reason for this is that I need to test that I can get to the same state from multiple places and I don't want to just duplicate the state like I have for other cases of this because the test for the state will need to be duplicated as well (since it's an identical state, unlike the others where they are different cases of the same state so despite being the same screen/location need a different test).

Conceptually, I think what I want is for @xstate/test to take every transition available to it, regardless of whether it has already visited that state or not. But not to take transitions it already has done so it doesn't start an infinite loop.

I think that's not possible with how @xstate/test and @xstate/graph work currently? Is there an alternative here apart from copy/pasting my state and test for the state to force it to take the transiton?

Here is my test model https://gist.github.com/UberMouse/229f330aafdb18aeeb984619a47107bf#file-testmodel-integration-ts-L145 linked to the specific transition @xstate/test is ignoring because it's already visited the state previously.

[davidkpiano]

There's a neat solution here: use nested states!

// instead of this:
states: {
  one: { on: { EVENT: 'final' } },
  two: { on: { EVENT: 'final' } },
  three: { on: { EVENT: 'final' } },
  final: {} // will only be reached once
}

// do this this:
states: {
  one: { on: { EVENT: 'final.one' } },
  two: { on: { EVENT: 'final.two' } },
  three: { on: { EVENT: 'final.three' } },
  final: {
    initial: 'default',
    states: {
      default: {},
      one: {},
      two: {},
      three: {}
    }
  }
}

This isn't a hack, and here's why: your intentions in the test ("test final from one", "test final from two", etc.) don't match the states in your machine... so you should translate your intentions to actual states ("test finalFromOne aka final.one, etc.)

[rjdestigter]

I use this strategy a lot when testing!

[UberMouse]

Ah, such an obvious solution now that I see it. Works great, thanks David.