You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 11, 2023. It is now read-only.
We have several situations in our tests where we want the return value of a function and use .toBe(...) to compare it with the desired outcome. There is no problem with synchronous functions to be handled this way. But there might be a problem with asynchronous functions, as they require an additional step, where we do not compare the result of the function itself but chain the expect.toBe into the .then part of the test. e.g.
test('the data is peanut butter', () => {
expect.assertions(1);
return fetchData().then(data => {
expect(data).toBe('peanut butter');
});
});
Or wait for the state to update with waitForState(). Otherwise we will pass tests even though they should be failing:
We have several situations in our tests where we want the return value of a function and use
.toBe(...)to compare it with the desired outcome. There is no problem with synchronous functions to be handled this way. But there might be a problem with asynchronous functions, as they require an additional step, where we do not compare the result of the function itself but chain theexpect.toBeinto the.thenpart of the test. e.g.Or wait for the state to update with

waitForState(). Otherwise we will pass tests even though they should be failing: