Helpers: nextTick/flushPromises

Follwing up on a discussion on Discord, I wanted to open this issue to gather feedback, experiences, and opinions on how to handle async testing and the usage of nextTick and flushPromises.

Differences between nextTick and flushPromises

I couldn’t explain it any better than here: https://github.com/testing-library/react-testing-library/issues/11

Current state of the art

We’re currently returning nextTick on several methods.

I think I was expecting to get away with await wrapper.something() most of the time.

by @cexbrayat. Turns out you might need an indeterminate number of nextTick calls to get everything up to date, so you end up using flushPromises. Happened the same to me while writing docs for HTTP requests.

Also, there’s this question by @JessicaSachs that is worth checking/considering:

nextTick might safely be able to be the default? I don’t remember if this prohibits testing of async created hooks (I’m thinking in Vue 2)

What are the alternatives?

1. “automagically” call flushPromises

The pros is that users have one less thing to worry about – and a thing which is quite low-level.

On the other hand, we might lose the ability to test intermediate states (such as “Loading states”) before the promise resolved/rejected. If that’s the case, this is a no-go.

2. Leave it as is and rely on docs

Pros is that current implementation of VTU-next would work.

Cons is that we all know that explaining something in a documentation does not translate well with “our users will know about this and will take it into account” 😅

3. Create a tool (method? helper?) to wrap nextTick and flushPromises

Not sure about the shape of that tool, but something along the lines of waitFor. Other alternatives mentioned on Discord are wrapper.findAsync.

---

disclaimer: this issue is meant to serve as a place to discuss alternatives. After that, if we reach a consensus, I open to write a proper RFC with the suggested proposal 👍

[lmiller1990]

We would probably include waitFor if Vue Testing Library didn’t already do that (which extends and builds on top of Test Utils, like React Testing Library builds on @react/test-utils. In general, I think Testing Library with the waitFor method is probably a more ergonomic alternative to Vue Test Utils for cases like this.

[cexbrayat]

Maybe my comment was misleading, I was talking about our (VTU) documentation.

As I said, it’s ok if you have a strong opinion on how that needs to be handled in your library: the point is the setTimeout with a 0 delay triggers the need for a second flushPromises, and other libs made different choices making it unnecessary. I understand that as a maintainer you don’t want to change that and introduce potential breaking changes (it’s the same for in VTU). We just need to inform developers using msw with VTU that a workaround exists in our docs. If anyone wants to open a PR on VTU docs, we’ll gladly review it 👍