Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

toObservable followed by toSatisfyOnFlush created double calls. #395

Open
rainoko opened this issue Oct 25, 2021 · 5 comments
Open

toObservable followed by toSatisfyOnFlush created double calls. #395

rainoko opened this issue Oct 25, 2021 · 5 comments

Comments

@rainoko
Copy link

rainoko commented Oct 25, 2021

  describe('toSatisfyOnFlush', () => {
    it('should verify mock has been called', () => {
      const mock = jest.fn();
      const coldObservable = cold('blah|');
      const stream$ = coldObservable.pipe(tap(mock));
      expect(stream$).toBeObservable(coldObservable);
      expect(stream$).toSatisfyOnFlush(() => {
        expect(mock).toHaveBeenCalledTimes(4);
      });
    });
  });

This test fails with call times actually 8 not 4. Even though it technically can be understandable, is is not intuitive when reading the test.

workaround is to separate this into 2 separate tests.

@Blafasel3
Copy link

Blafasel3 commented Jun 29, 2022

What I did was to put the toBeObservable Code inside the toSatisfyOnFlush block. But I agree, it is counterintuitive.

      expect(stream$).toSatisfyOnFlush(() => {
          expect(stream$).toBeObservable(coldObservable);
          expect(mock).toHaveBeenCalledTimes(4);
      });

@despeekapool
Copy link

Hi!
Is there any specific reason for not having the flush logic directly implemented within the toBeObservable() like jasmine-marbles does?
This would be super helpful 😅

@killergege
Copy link

I came here for the same problem, I followed your suggestion @Blafasel3, but when inside the toSatisfyOnFlush(), the expect().toBeObservable() always pass, whatever the coldObservable I'm testing...

For instance, this fails as expected, but triggers the observable several times :

    const stream$ = hot('a', { a: myAction(payload) });
    const coldObservable = cold('b', { b: undefined });

    expect(stream$).toBeObservable(coldObservable);
    expect(stream$).toSatisfyOnFlush(() => {
      expect(mock).toHaveBeenCalledTimes(4);
    });

But this pass while it shouldn't:

    const stream$ = hot('a', { a: myAction(payload) });
    const coldObservable = cold('b', { b: undefined });

    expect(stream$).toSatisfyOnFlush(() => {
      expect(stream$).toBeObservable(coldObservable);
      expect(mock).toHaveBeenCalledTimes(4);
    });

I have other asserts in the toSatisfyOnFlush that fail when I change them, so I don't understand why the expect doesn't fail...
I'm using Jest 28.1.3 & jest-marbles 3.0.2

@just-jeb
Copy link
Owner

@killergege Interesting, I'll take a look.

@Blafasel3
Copy link

I came here for the same problem, I followed your suggestion @Blafasel3, but when inside the toSatisfyOnFlush(), the expect().toBeObservable() always pass, whatever the coldObservable I'm testing...

For instance, this fails as expected, but triggers the observable several times :

    const stream$ = hot('a', { a: myAction(payload) });
    const coldObservable = cold('b', { b: undefined });

    expect(stream$).toBeObservable(coldObservable);
    expect(stream$).toSatisfyOnFlush(() => {
      expect(mock).toHaveBeenCalledTimes(4);
    });

But this pass while it shouldn't:

    const stream$ = hot('a', { a: myAction(payload) });
    const coldObservable = cold('b', { b: undefined });

    expect(stream$).toSatisfyOnFlush(() => {
      expect(stream$).toBeObservable(coldObservable);
      expect(mock).toHaveBeenCalledTimes(4);
    });

I have other asserts in the toSatisfyOnFlush that fail when I change them, so I don't understand why the expect doesn't fail... I'm using Jest 28.1.3 & jest-marbles 3.0.2

Oh, I never actually tested that. Thanks for pointing that out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants