Skip to content

[Feature]: add a waitBeforeRetry option to jest.retryTimes #13659

@saltman424

Description

@saltman424

🚀 Feature Proposal

It would be nice to be able to tell Jest to wait some amount of time before retrying tests. I think for most use cases, just a static number of milliseconds would be sufficient.

Motivation

The use case that I am running into is: I have a test that modifies some data, and then a subsequent tests that query the data and then ensure that data is the updated data. However, since there is some caching for the queries (on the back-end), I sometimes need to wait a little bit to get the updated data. So the sequence I would want is:

  1. Test 1: update data
  2. Test 2: get updated data - fails because cached data is returned
  3. Wait some amount of time (e.g. 10 seconds)
  4. Test 2 retry: get updated data - succeeds because cached data is no longer returned

Another case I could see benefitting from this is network errors or other temporary issues, but I think most of the time, that type of case can and should be handled by putting retry logic in the client that is making the network request.

Example

describe('Updating item', () => {
  const originalItem: Item = { ... }
  const updatedItem: Item = { ... }

  test('should succeed', async () => {
    await updateItem(originalItem.id, updatedItem)
  })

  describe('subsequent queries', () => {
    jest.retryTimes(3, { waitBeforeRetry: 10e3 })
  
    test('getting item should show updates', async () => {
      const item = await getItem(originalItem.id) // Might return cached results
      expect(item).toEqual(updatedItem)
    })

    test('item list should show updates', async () => {
      const items = await listItems() // Might return cached results
      expect(items).toContainEqual(updatedItem)
    })
  })
})

Pitch

The reason I want this in jest.retryTimes is because cached data doesn't cause the request itself to fail, it just causes one of the following expect assertions to fail. So the necessary retry logic must be put in the test suite.

To be honest, I am not sure there are many cases where I would use jest.retryTimes without a waitBeforeRetry option since most of the time if there is an error that an immediate retry would solve, I would prefer to implement that retry logic in the underlying client or service. To me, jest.retryTimes should mostly be used when there is not an error in the request but rather in the expect assertions (generally due to caching or eventual consistency).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions