flushPromises() once again - how about waitForExpect

[lgandecki]

Hey Kent!
Fantastic work!

I was doing an intro to TDD workshop yesterday and decided to use your library instead of enzyme, as I did in the past. I also did much less unity-style of testing, following the principle of "use it as a user would" instead. It went a bit less smooth than I would like, but the guys were excited and liked it, for the most part. :-) I think I told you about this - we just code for hours on end without touching the browser, and then in the end, after the last test turns green, we open our browsers hoping for the best.. this time, 5/5 apps worked, it feels like magic. And with your framework we were able to do this MUCH quicker than before, writing many fewer tests, but still ending up having the same end result - very high level of confidence in the app. And easier to refactor. :)

To the point - there was one thing missing for me in this kind of testing when I was quickly rewriting my notes.

I have a component that loads a data from an external API. I mock it everywhere else, but in one place I do the full e2e call, to verify that it's correct.
https://github.com/TheBrainFamily/TDD-NASA-POD/blob/final/src/__tests__/UnmockedPicture.test.js#L19

test("Displays a title, description and link for a picture after fetching it from actual API server", async () => {
  const { getByTestId, getByText } = render(
    <Picture date={CONTRACT_TEST_DATE} />
  );

  expect(getByText("Loading...")).toBeTruthy();

  await waitForExpect(() => {
    expect(getByTestId("title").textContent).toEqual(
      "NGC 1316: After Galaxies Collide"
    );
    expect(getByTestId("description").textContent).toMatch(
      /An example of violence on a cosmic scale/
    );
    expect(getByTestId("link").src).toMatch(/1024d/);
  });
});

I want to see the loader, and then the component actually renders the fetched data. But it comes back at a random time and I definitely NOT want to put my expectation in setTimeout(). So I went ahead and created a simple tool called waitForExpect ( https://github.com/TheBrainFamily/wait-for-expect/ - btw, looks like one of your guys at PayPal already somehow found it and starred it! Made my day ;-) ).

It basically repeats the expectation over and over and in the end - if things are not working correctly - instead of timing out it gives you a familiar from your test runner error.

I thought it would be great to use it also for the mocked calls -
https://github.com/TheBrainFamily/TDD-NASA-POD/blob/final/src/__tests__/App.test.js#L119

Thinking as a user - I don't want to think about flushing promises, isn't this a very low-level detail in otherwise such a nicely user/developer-oriented library? :) I remember the first time I stumbled upon this problem with react, it took me a few hours of debugging to figure out how to get this to work. I think you can be a very successful frontend dev without understanding the problem of flushing promises and what is setImmediate doing.

The thing that makes me feel like this is the right way (but I can be wrong! wouldn't be the first time), is the fact that I use the same abstraction in both mocked and integration (or e2e) testing.
If I set up my mock that way and programmatically turn it off/on I could basically run the same test, one with a remote server, and one with mocked data, having this way a really nice contract test.

I was curious what would you think about recommending (or including) this tiny tool in your docs?

Thanks!

Edited: there is one more thing I forgot to mention. When after a result of flushing promises another promise is queued, you have to flush promises twice. This happens for example when using a mockednetworkinterface with apollo and components wrapped with multiple queries. And then those components in turn run more queries. They fire one after another and I ended up adding tens of those flushes in a helper to get it to work. Now I will just use this waitForExpect instead and just stop worrying :-)

[kentcdodds]

It seems like a nice abstraction! I'm not 100% certain I want to include it in this library though. This library is intended for integration and unit testing. E2E was never a goal for this library. Though now that I think about it I'm not sure why not... I'll have to give it some thought. I do worry that this library would get over bloated.

What I'd prefer for now is that we add a link in the README (maybe another entry in the FAQ) that refers to this problem and an example of using wait-for-expect. Seems like a pretty good compromise for now I think.

[kentcdodds]

Actually, I'm starting to think this might be a good thing to include. I'll explain more later, but if you'd like to start work on a PR I think we'll merge it 👍

[lgandecki]

Cool. I'd love to hear more about what you are thinking. I've started with cleaning up the code and adding tests for all possible use of the command. I wanted this to be top-notch if it ended up being used or even recommended here. I've added a WIP PR, so you can comment if this is going into the direction you were thinking.
Thanks!