dom-testing-library icon indicating copy to clipboard operation
dom-testing-library copied to clipboard

Specify ontimeout at configuration level

Open SimonGodefroid opened this issue 3 years ago • 5 comments

Is there a way to specify an onTimeout function at top level?

We are having some flaky tests and I'd like to be able to print the screen when some of the timeouts occur because we figured in some cases the printed DOM during timeouts is really not what we're expecting.

Context:

some tests fails every once in a while because we render the app and redirect to a specific route and sometimes 2 tests that run in a row, the second one is not starting at the redirect location at the beginning of the test but at the location where the previous test stopped (when you click on the submit button of a form, mock with msw a patch request and that the code redirects to the details page). For that case we have set the DEBUG_PRINT_LIMIT in the CI command to be able to see the mounted DOM and figured that weird case.

Motivation:

We have new flaky tests and this time the error message in the CI is:

Error: expect(element).toBeInTheDocument()

element could not be found in the document
    at Object.<anonymous> (/home/circleci/project/src/***.test.tsx:39:53)
    at _callCircusTest (/home/circleci/project/node_modules/jest-circus/build/run.js:212:5)
    at _runTest (/home/circleci/project/node_modules/jest-circus/build/run.js:149:3)
    at _runTestsForDescribeBlock (/home/circleci/project/node_modules/jest-circus/build/run.js:63:9)
    at _runTestsForDescribeBlock (/home/circleci/project/node_modules/jest-circus/build/run.js:57:9)
    at run (/home/circleci/project/node_modules/jest-circus/build/run.js:25:3)
    at runAndTransformResultsToJestFormat (/home/circleci/project/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapterInit.js:176:21)
    at jestAdapter (/home/circleci/project/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapter.js:109:19)
    at runTestInternal (/home/circleci/project/node_modules/jest-runner/build/runTest.js:380:16)
    at runTest (/home/circleci/project/node_modules/jest-runner/build/runTest.js:472:34)

Locally I wrote a purposefully broken statement to see whether I could leverage on onTimeout function to print the DOM as it was when the code failed.

expect(
      await screen.findByText(
        /LOLLLLLL/i,
        {},
        {
          onTimeout: err => {
            console.log('>>>'.repeat(200),err);
            screen.debug(null, 10000000000);
          }
        }
      )
    ).toBeInTheDocument();

I would like to know how I can specify an onTimeout function or whether I can use getElementError to achieve this.

SimonGodefroid avatar Oct 17 '22 12:10 SimonGodefroid

Putting logs in the setupTest's configure object is also behaving weirdly, like it's logging the error a lot of times:

configure({
    asyncUtilTimeout: 2000,
    getElementError: (message, container) => {
      console.log('>'.repeat(20), 'container', container, 'message', message);
      // screen.debug(null, 10000000000);
      return new Error(message!);
    }
  });

SimonGodefroid avatar Oct 17 '22 13:10 SimonGodefroid

  console.log
    >>>>>>>>>>>>>>>>>>>> container HTMLBodyElement {
      [Symbol(SameObject caches)]: [Object: null prototype] {
        attributes: NamedNodeMap {},
        childNodes: NodeList {}
      }
    } message Unable to find an element with the text: /LOOLLL/i. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

      at Object.getElementError (src/setupTests.ts:80:17)

SimonGodefroid avatar Oct 17 '22 13:10 SimonGodefroid

Hey, I would like to work on this issue if it's still relevant 🙏

naorpeled avatar May 22 '23 15:05 naorpeled

@naorpeled go for it, we're here to assist if you need :)

MatanBobi avatar May 23 '23 06:05 MatanBobi

Hey @SimonGodefroid,

It seems that getElementError should cover your use case. The expectation that it would be only invoked once is covered in one of the library's tests, so I'm not entirely sure that the issue lies within the library itself.

My guess is that it was already fixed in one of latest versions.

naorpeled avatar Jun 10 '23 14:06 naorpeled