testing-library / dom-testing-library

🐙 Simple and complete DOM testing utilities that encourage good testing practices.
https://testing-library.com/dom
MIT License
3.26k stars 466 forks source link

Specify ontimeout at configuration level #1179

Closed SimonGodefroid closed 2 months ago

SimonGodefroid commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
  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)
naorpeled commented 1 year ago

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

MatanBobi commented 1 year ago

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

naorpeled commented 1 year ago

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 commented 2 months ago

Hey, as this issue is stale I'll leave an example before @MatanBobi will close it.

import {configure} from '@testing-library/dom'
configure({
  getElementError: (message, container) => {
    const customMessage = [message, container.firstChild].join(
      '\n\n',
    )
    return new Error(customMessage)
  },
})
MatanBobi commented 2 months ago

Thanks @naorpeled. @SimonGodefroid please try the approach that Naor shared here. If you don't find it as a proper solution. please comment here or re-open :)