waitForTime() util

[JorensM]

Clear and concise description of the problem

I'd like to have a waitForTime() utlity function that would wait a specified amount of time before proceeding with the next lines of code. I know I know, manual waiting is frowned upon in testing, but I have a real case where I need to run a click/keyboard event at specific intervals of time, because such is simply the nature of the component.

Suggested solution

Honestly no idea.

Alternative

Right now I've implemented a function:

export default function sleep(milliseconds: number) {
    return new Promise((resolve) => {
      setTimeout(resolve, milliseconds);
    });
}

But it's inconsistent and sometimes the recorded intervals are much longer than the provided sleep value. I'd be okay with some margin of error, but right now it tends to wait for 60 seconds when I only specified to sleep for 2 seconds.

Additional context

Basically, the component I want to test is used to set a rhythm by repeatedly tapping/clicking on the page. So yeah, I'd like to test this feature if possible.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[hi-ogawa]

I'm not sure what you are suggesting. It's helpful if you have a concrete example to demonstrate how new API waitForTime would be useful.

[github-actions[bot]]

Hello @JorensM. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[JorensM]

I'm not sure what you are suggesting. It's helpful if you have a concrete example to demonstrate how new API waitForTime would be useful.

Sorry for the ambiguity. Here is an example:

   const tappableElement = await getByText('Tap me twice to set the rhythm');
    
   await tappableElement.click() // First click to set the interval start
   await waitForTime(4000); // Wait 4000 milliseconds before proceeding
   await tappableElement.click() // Second click happens after 4 seconds and sets the interval to 4 seconds, and now a script can be run in the app every 4 seconds, or the interval duration can be stored somewhere for further use.

If it's still not clear what the use case would be, please see https://time-to-sleep.vercel.app/breathing as an example of what I mean.

Here is another example of this being done in FL Studio (music production software) to set the BPM of the track: https://youtu.be/pxgv6BA0r2c?si=SPTXCa0dYoQenPhn&t=260 (at 4:20)

[hi-ogawa]

@JorensM I appreciate the example, but I failed to see what's intended to happen in await waitForTime(4000). How is it different from await new Promise(resolve => setTimeout(resolve, 4000))?

[JorensM]

@hi-ogawa It's not conceptually different, in both cases the program waits for the time to pass before proceeding, but I thought maybe we could come up with a more efficient and precise method that plays along well with the testing library. As noted before, currently implementing it in the way that you suggested is inconsistent and sometimes the program waits for far longer than the specified time. I'm guessing that this is due to some background processes happening with the library that slows down the execution of the test.

[hi-ogawa]

As noted before, currently implementing it in the way that you suggested is inconsistent and sometimes the program waits for far longer than the specified time.

At the moment, I don't have any idea where that inconsistency comes from. Can you provide a reproduction? I guess that can be said a bug as well. Otherwise, we don't know what kind of "a more efficient and precise method" you're looking for.

[JorensM]

As noted before, currently implementing it in the way that you suggested is inconsistent and sometimes the program waits for far longer than the specified time.

At the moment, I don't have any idea where that inconsistency comes from. Can you provide a reproduction? I guess that can be said a bug as well. Otherwise, we don't know what kind of "a more efficient and precise method" you're looking for.

Sure, you can clone https://github.com/JorensM/time-to-sleep and run the BreathingExercises.test.tsx test. If you try running it a few times, you might notice that the Should start automatically switching between the texts 'breathe in' and 'breathe out' according to the specified rhythm test will occasionally fail due to the sleep() function hanging and wait for far more seconds than specified

as for 'a more efficient and precise method', I wasn't talking about optimizing it, sorry if it sounded that way. I just suggested that something in vitest might be interfering with the sleep()ing and causing the extra long delay. I'll try to check vitest's source but I honestly have no idea where I could possibly start.

[hi-ogawa]

Looking at https://github.com/JorensM/time-to-sleep/blob/0964a548084a8b9e0cd4244b83e5e349848d0575/src/__tests__/BreathingExercises.test.tsx#L38-L44, it's possible that each expect.element or click call auto-retries and that can skew the time which you might expect at the specific line. I'd suggest debugging the time around there by writing console.log(new Date()) before and after each line to see whether you get what you expect.

[JorensM]

Looking at https://github.com/JorensM/time-to-sleep/blob/0964a548084a8b9e0cd4244b83e5e349848d0575/src/__tests__/BreathingExercises.test.tsx#L38-L44, it's possible that each expect.element or click call auto-retries and that can skew the time which you might expect at the specific line. I'd suggest debugging the time around there by writing console.log(new Date()) before and after each line to see whether you get what you expect.

• The time before the sleep(2000) function: 2025-01-05T00:20:28.994Z.
• The time right after: 2025-01-05T00:20:31.002Z.

So the dates show a correct, 2 second difference. So the sleep function does indeed wait for 2 seconds.

The recorded interval: 5.008 seconds (the recorded time interval between the first and second click, which should be 2 seconds).

This would suggest that either the element does not get found right away and auto-retries, or that click()/getByText() have some stuff going (probably the former as it most often is haha). I'll try to see if there's any reason it doesn't get found right away. Also, is there any way to log the amount of retries a click()/getByText() function does?

Another possibility is that the initial click() before the sleep() function fires the click event asynchronously and proceeds before the even has been fired (I'm not sure how DOM events work in that regard).

[JorensM]

Could it also be possible that my CPU hangs which causes the delay? Or does JavaScript take that into account?

[AriPerkkio]

If you want to test timing precisely, you should not rely on real timers. Instead, use vi.useFakeTimers(). So something like this in your case:

+ vi.useFakeTimers();
 await expect.element(initialText).toBeVisible();
 await initialText.click();
 await expect.element(breatheInText).toBeVisible();

- await sleep(2000);
+ vi.advanceTimersByTime(1999)

+ // In-text should still be visible
+ await expect.element(breatheInText).toBeVisible();
+ // Out-txt should not yet be visible
+ await expect.element(breatheOutText).toBeVisible();

+ vi.advanceTimersByTime(1)
+ // Should become visible now
 await breatheInText.click();
 await expect.element(breatheOutText).toBeVisible();

[hi-ogawa]

I'll move this to a discussion as I'm not sure the exact objective of the feature and this feels more like a question of your app's testing strategy. Please try out Ari's fake timer approach.