Having issues testing an event in xstate/test

[ssuttoplunz]

Hello!
I am having issues trying to test my code, where not all of the paths are actually being run with xstate test. See the example below, where I have described a few quick changes to the xstate-test-demo repo that replicate the issue.

In App.test.js the feedbackMachine has form in the states attribute:

form: {
        on: {
          SUBMIT: [
            {
              target: 'thanks',
              cond: (_, e) => e.value.length
            }
          ],
          CLOSE: 'closed'
        },
        meta: {
          test: ({ getByTestId }) => {
            assert.ok(getByTestId('form-screen'));
          }
        }
      },

If I add an event, in this case I called it RESET (it could be any event), with a { target: 'closed' } (it is a different state that exists in the machine), along with an empty event in the testModel (so it doesn't fail) it actually runs the test using the RESET event.

// this would be in the Machine's "form.on" section 
          RESET: {
            target: 'closed'
          }

// this would be in the testModel events section
      RESET: () => {
        console.log('something')
      },

Then the test runs and it shows via CLICK_BAD → RESET is tested
Result:

  feedback app
    ✓ coverage (1ms)
    reaches state: "question" 
      ✓ via  (33ms)
    reaches state: "thanks" 
      ✓ via CLICK_GOOD (12ms)
      ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) (11ms)
    reaches state: "closed" 
      ✓ via CLICK_GOOD → CLOSE (6ms)
      ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) → CLOSE (8ms)
      ✓ via CLICK_BAD → CLOSE (7ms)
      ✓ via CLICK_BAD → RESET (69ms)
      ✓ via CLOSE (7ms)
    reaches state: "form" 

However, if you change RESET to { target: 'form' } instead of { target: 'closed' } (e.g. the same state) it does not test it:

// this would be in the Machine's "form.on" section 
          RESET: {
            target: 'form'
          }

// this would be in the testModel events section
      RESET: () => {
        console.log('something')
      },

Result:

  feedback app
    ✓ coverage
    reaches state: "question" 
      ✓ via  (31ms)
    reaches state: "thanks" 
      ✓ via CLICK_GOOD (12ms)
      ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) (10ms)
    reaches state: "closed" 
      ✓ via CLICK_GOOD → CLOSE (5ms)
      ✓ via CLICK_BAD → SUBMIT ({"value":"something"}) → CLOSE (7ms)
      ✓ via CLICK_BAD → CLOSE (7ms)
      ✓ via CLOSE (3ms)
    reaches state: "form" 
      ✓ via CLICK_BAD (5ms)

Notice: there is no event RESET in the "form" section

I guess my question is, is this by design? Or is it a bug? I am just trying to understand if this is possible with xstate test or if I should be going about this in a different manner. While it might appear having an event go back to the original state doesn't do much, in my case I have an action associated with it, which then returns it to the original state, and want to ensure the action is performed.

Thanks!

[davidkpiano]

✏️ Please create a CodeSandbox (XState template) reproduction of this. Thanks!

[ssuttoplunz]

I think I did this right, I don't use sandbox too frequently, so let me know if it doesn't work:

I imported the xstate-test-demo repo for consistency with what I described above, and the two additions of code are marked with // here is the addition in App.test.js.

https://codesandbox.io/s/intelligent-dew-l11n7?file=/src/App.test.js

[davidkpiano]

For each individual path, the testing algorithm is going to avoid cycles whenever possible. If you go:

CLICK_BAD -> form -> REST -> form

Then to avoid this from happening:

form -> RESET -> form -> RESET -> form

It remembers that it already visited the form state, and prevents visiting it again (i.e., prevents executing RESET) to avoid an infinite cycle.

To fix this, you need to tell the model that "the default form state" is characteristically different than "the form state after resetting". One simple way to do this is to use nested states:

      form: {
        initial: 'default',
        states: {
          default: {},
          resetted: {}
        },
        on: {
          SUBMIT: [
            {
              target: "thanks",
              cond: (_, e) => e.value.length
            }
          ],
          CLOSE: "closed",
          RESET: {
            target: "form.resetted"
          }
        },

Then, because form.default is different than form.resetted, the algorithm will take the form.default -> RESET -> form.resetted path.

[ssuttoplunz]

Thank you, will do!