JSPM

  • ESM via JSPM
  • ES Module Entrypoint
  • Export Map
  • Keywords
  • License
  • Repository URL
  • TypeScript Types
  • README
  • Created
  • Published
  • Downloads 574810
  • Score
    100M100P100Q183629F
  • License MIT

Wait for expectation to be true, useful for integration and end to end testing

Package Exports

  • wait-for-expect

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (wait-for-expect) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

code style: prettier CircleCI

wait-for-expect

Wait for expectation to be true, useful for integration and end to end testing

Usage:

const waitForExpect = require("wait-for-expect")

let numberToChange = 10;

test("it waits for the number to change", async () => {
  setTimeout(() => {
    numberToChange = 100;
  }, 600);
  
  await waitForExpect(() => {
    expect(numberToChange).toEqual(100)
  });
});

instead of:

let numberToChange = 10;

test("it waits for the number to change", () => {
  setTimeout(() => {
    numberToChange = 100;
  }, 600);
  
  setTimeout(() => {
    expect(numberToChange).toEqual(100);
  }, 700);
});

It will check whether the expectation passes right away after flushing all promises (very useful with, for example, integration testing of react when mocking fetches, like here: https://github.com/kentcdodds/react-testing-library#usage)

If it won't, it will keep repeating for the default of 4.5 seconds, every 50 ms.

Nice thing about this simple tool is that if the expectation keeps failing till the timeout, it will check it one last time, but this time the same way your test runner would run it - so you basically get your expectation library error, the sam way like if you used setTimeout to wait but didn't wait long enough.

If I change the expectation to wait for 105 in above example, you will get nice and familiar:


 FAIL  src/waitForExpect.spec.js (5.042s)
  ✕ it waits for the number to change (4511ms)

  ● it waits for the number to change

    expect(received).toEqual(expected)
    
    Expected value to equal:
      105
    Received:
      100

       9 |   }, 600);
      10 |   await waitForExpect(() => {
    > 11 |     expect(numberToChange).toEqual(105);
      12 |   });
      13 | });
      14 | 
      
      at waitForExpect (src/waitForExpect.spec.js:11:28)
      at waitUntil.catch (src/index.js:61:5)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        5.807s

API

waitForExpect takes 3 arguments, 2 optional.

/**
 * Waits for predicate to not throw and returns a Promise
 *
 * @param  expectation  Function  Predicate that has to complete without throwing
 * @param  timeout  Number  Maximum wait interval, 4500ms by default
 * @param  interval  Number  Wait interval, 50ms by default
 * @return  Promise  Promise to return a callback result
 */

Credit

Based on ideas from https://github.com/devlato/waitUntil - mostly build around it with functionality nice for testing. Couldn't depend on it internally because I wanted to add the flushPromises and run the initial expectations right after flushing them, which had to be done in the tool itself :) otherwise tests that should be taking few ms would take all >50ms in the default situation. It might seem trivial but with 100 tests times 45 ms extra your tests would start taking 4.5 seconds instead of 0.5 s :)