Store: Unit testing documentation

[kctang]

I am having some issues with the example provided on unit test page. Does not work for me.

This was from the docs (does not work):

      it('it toggles feed', () => {
        store.dispatch(new FeedAnimals());
        store.selectOnce(state => state.zoo.feed).subscribe(feed => {
          expect(feed).toBe(true);
          // NOTE: i think at least need a "done()" here (and as param for this test function)
        });
      });

After some tweaking of my own, I got two versions working.

1. This works for me using async/await and toPromise() as needed:

      it('it toggles feed with async/await', async () => {
        // await because dispatch may take a longer time.
        await store.dispatch(new FeedAnimals()).toPromise();
        const feed = store.selectSnapshot(state => state.zoo.feed)
        expect(feed).toBe(true);
      });

1. A singlesubscribe() for an Observable stream and done() to complete the asynchronous test (I think piping from dispatch() is optional, should we bother?):

  it('it toggles feed without async/await', done => {
    store.dispatch(new FeedAnimals()).pipe(
      concatMap(() => store.selectOnce(state => state.zoo.feed))
    ).subscribe(
      feed => {
        expect(feed).toBe(true)
        done()
      }
    )
  })

I should also mention that my Angular project uses Jest for unit testing. The configuration was roughly based on this article.

Q: So, any recommendation on whether we should use "async/await with toPromise()" or a "subscribe() with done()" for these unit tests? Or you recommend some other ways?

[amcdnl]

@deebloo - Can you help?

[deebloo]

@amcdnl yes I can take a look at the docs

[deebloo]

the done does matter in this case. It will depend on your actions. by default observables are actually synchronous so if your action is async you may have to add your listener BEFORE you dispatch your action

[kctang]

I think you are referring to the fact that Actions in ngxs can make state changes via sync (direct state chain, plain reducer) or async (middleware, side-effects). In the case of sync, then we can just check state after the dispatch. This is what the demo unit test code does.

However, for async, we have to do something like my example above (either approach works).

My question was to seek recommended/best practice for unit testing ngxs actions with side-effects.

I suggest update the docs with separate sections to describe testing sync actions and async actions (i am not sure if these are the right terms ) scenarios to make it clear to new users.

[garthmason]

Yep, I'd agree with @kctang it'd be good to get a few more examples here, we've been having a little trouble here understanding how we should test these scenarios.
On the whole though we are finding the library easy to use, we've got two feature teams working with NGXS for the last few weeks, overall experience is very positive 😃

[deebloo]

Ok I understand better. Now. Maybe over the weekend I'll have time to throw in some unit testing recipes or something along those lines

[amcdnl]

I added some more unit testing docs. Feel free to PR anything you find valuable.

[eranshmil]

Just to let you know, I also had this issue and updating jest to version 23 solved it.

[jessethach]

I don't know if anyone has come across this issue, but I am receiving a SPEC HAS NO EXPECTATIONS should dispatch YOUR_ACTION action. The test is throwing up a false positive. I think these docs are incorrect.

Running Angular 7, Angular CLI 7, TypeScript 3, with:

"@ngxs/devtools-plugin": "^3.2.0", "@ngxs/form-plugin": "^3.2.0", "@ngxs/router-plugin": "^3.2.0", "@ngxs/storage-plugin": "^3.2.0", "@ngxs/store": "^3.2.0",