dom-testing-library: Custom testIdAttribute ignored

  • @testing-library/dom version: 7.29.4
  • Testing Framework and version: Jest
  • DOM Environment:

Relevant code or config:

configure({ testIdAttribute: 'foobar' })

What you did:

Happily seeing getByTestId work, then I bumped to this version of dom-testing-library, and it stopped working.

What happened:

It’s clearly ignoring the config and searching for the default data-testid: TestingLibraryElementError: Unable to find an element by: [data-testid="bar"...

Reproduction:

Use configure({ testIdAttribute }) in any environment and see that it’s broken now.

Problem description:

Hundreds and hundreds of tests break.

Suggested solution:

It’s unfortunately hard to figure out where this broke because we get our dom-testing-library via @testing-library/react, which carets it, meaning it jumps from 7.27.1 -> 7.29.4. Somewhere in the commits in dom-testing-library between those two version numbers is the regression.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 19 (10 by maintainers)

Most upvoted comments

Maybe we can implicitly state that there’s no need to install @testing-library/dom since everything is already exported from @testing-library/react, Wdyt?

You mean “explicitly”? If not then I don’t think that “implicit documentation” works.

It would still be nice to confirm if this is indeed the problem.

Happened to me today again. For further readers, if you are using Yarn, simply check that you have only one version of @testing-library/dom with

yarn why @testing-library/dom

If it discovers more than one version, upgrade all dependants and when it’s not possible, try Yarn resolutions

"resolutions": {
    "@testing-library/dom": "preferred version"
},

That’s a lint warning from the AirBnB lint config - they should really document when to disable it, e.g., for test files and local development scripts.

Thanks for the report.

I definitely understand your frustration here. Let me quickly explain the problem.

@testing-library/react depends on @testing-library/dom. If you configure @testing-library/react you also configure the version @testing-library/react uses of @testing-library/dom. However, if you explicitly declare @testing-library/dom in your package.json it is not guaranteed that the version of @testing-library/dom you import is the same as @testing-library/react uses.

In the current state you would have to guarantee that. We could make @testing-library/dom a peer dependecy of @testing-library/react but that would mean more setup steps required for users of @testing-library/react.

Could you share a reproducible example where this problem occurred and explain a bit more about how you use @testing-library/react and @testing-library/dom? Because “It seems that if you bump @testing-library/react to 11.2.2+, you must also bump @testing-library/dom to the latest available version at the same time.” seems unintended.

We may just want to re-export everything from @testing-library/dom so that you don’t have to install that separately.

I think we already do re-export everything from @testing-library/dom here and actually there’s no real need to install @testing-library/dom as far as I remember and as far as the docs say here.