nickserv
commented
3 years ago I'm seeing two related issues here, so I'll split up my response:
Supporting different frameworks
As far as I'm aware, while we primarily focus on Jest support, we still want to support other test frameworks. Testing Library shouldn't necessarily require Jest, it's just a convenient option because of its simple extensible APIs and built in JSDOM support, and it's already popular in the React community.
That being said, I have seen some bugs in some of our packages caused by us assuming a JSDOM environment in Jest, which can cause issues with supporting a real DOM, such as in web-test-runner. I'm assuming that your issue is either related to DOM support or ES module support. Either way, I would appreciate it if you could post an example (preferably one we could run locally) showcasing your specific issues with using DOM Testing Library in web-test-runner.
Using only queries
Because DOM Testing Library doesn't rely on any specific web framework, it works with plain DOM Nodes, so its queries should already be useful in isolation. If you don't want the entire package namespace imported, you have three options:
- Import
screento use any query on the entire document:import { screen } from "@testing-library/dom" - Import specific queries to use them on any element:
import { getByText } from "@testing-library/dom" - Import
queriesto use any query on any element:import { queries } from "@testing-library/dom"
From a packaging optimization perspective, I'm not sure how well we support tree shaking, which would let build tools remove other parts of the library that queries don't depend on. If you have a situation where you need to use Testing Library in production but your bundle is too build, I can try to help you look into that if you can post more information, such as the results of running webpack bundle analyzer.
From a package maintenance perspective, separating out our queries into a separate package would require additional infrastructure and manual package dependency bumps (which is a bit trickier to keep track of since we're not using monorepos/workspaces). DOM Testing Library doesn't have too many dependencies, and as long as tree shaking is working properly they can be removed when they're not used anyway. Additionally, I think it's worth noting that our framework specific packages like React Testing Library wrap other DOM Testing Library APIs such as waitFor, so just importing the queries wouldn't be enough.
Example
Let's say you were writing a debugging tool that prints a DOM Node in the console after asking the user for its text content, so you don't care about our other testing utilities such as waitFor, Jest DOM, or React Testing Library. You could import only the queries you want to use and use the DOM Nodes they return.
import { screen } from "@testing-library/dom";
const text = prompt("Type in the text of a Node to get");
if (text) {
const node = screen.getByText(text);
console.log(node);
} else {
console.log("Node not found");
}
jimsimon
alexkrolick
TimvdLippe
sijakret
eps1lon
sheremet-va
plusgut
github-actions[bot]
thebuilder
Edit 2: Per request, I've simplified this down to a few simple questions and answers.
What did you do? I attempted to use dom-testing-library in a test suite that's be run via Web Test Runner.
What happened? The test runner bombed out complaining about CJS modules that are dependencies of dom-testing-library: aria-query, corejs, and lz-string. There may be more but that's as far as I spent time digging into them.
What did you expect to happen? I expected the test runner to actually run without dependency errors.
Is there a repro? https://github.com/jimsimon/wtr-dtl/tree/wtr-using-wds (note the branch name)
What have you tried so far? I've tried using the Web Test Runner's CJS support that leverages Rollup's CJS plugin but that did not help. It appears the dependencies causing the errors are not supported by Rollup's CJS plugin.
Is there a proposed solution? Upgrade to versions of these dependencies that support native ES modules or migrate to alternatives that do.
Any other notes? One of the conflicting dependencies (aria-query) was updated in #1058 so that one may no longer be problematic. I haven't had a chance to test it though. I just tried the repro with the latest versions of all dependencies and I'm still having issues.
------------------------------------------------ FIRST EDIT STARTS BELOW -----------------------------------------------------------
Edit: This issue originally started as a request to have dom-testing-library broken down into separate packages to make it easier to consume by non-Jest based test runners. It has since transformed into a discussion about what's preventing dom-testing-libary form working with web-test-runner. In an effort to focus this ticket, I've copied the relevant parts of the conversation below.
First a TLDR: dom-testing-library does not work with web-test-runner. Multiple dependencies used by dom-testing-library do not publish native esm modules and are not compatible with rollup's commonjs plugin (which can be used by web-test-runner). One big offender is aria-query, which may be fixed with #1058 but has not been tested yet. Main repro can be found in https://github.com/jimsimon/wtr-dtl/tree/wtr-using-wds (note the branch name since there are multiple different repros for different attempts to workaround the problem in this repo).
This is the end of the conversation as of this edit. Hopefully this helps!
--------------------------- ORIGINAL ISSUE DESCRIPTION BELOW -------------------------------------------------
Describe the feature you'd like:
I'd love to be able to use the queries provided by testing-library in other testing frameworks. This would allow for a gradual migration to testing-library for codebases with existing test frameworks/runners that aren't compatible with testing-library. One example of a test runner that doesn't play nicely with dom-testing-libary is web-test-runner. Splitting the queries out to a separate package would allow more people to use them and help improve testing in the larger JS ecosystem. This should be doable without any breaking changes, as the existing API's could just delegate to the new package.
Suggested implementation:
Create a new
@testing-library/queriespackage and move all query related code to it.Describe alternatives you've considered:
The only alternative I can think of would be to reimplement the same queries in an entirely new project. This seems like wasted effort if we can simply extract the ones that testing-library already provides.
Teachability, Documentation, Adoption, Migration Strategy:
There should be no outward facing impact on users as API's would remain backwards compatible. Documentation for the new package would need to be created, and some minor documentation updates might be needed for the main site.