Comments (20)
I think we should add something like this to dom-testing-library instead. I was thinking about it for the initial release but didn't have time and didn't want to rush it.
from react-testing-library.
This is why we suggest people use @testing-library/user-event
which may eventually be built-in.
I'm excited about the events being attached to the root. Because they were attached to the document
we had to render everything into document.body
for events to work properly (which is where the limitation came from). This meant we had to get creative with cleanup.
However, I'm actually pretty happy with what we have now and I don't see a reason to change. I think it still makes the most sense to actually render everything in document.body
and have automatic cleanup like we do. I feel like this will result in the fewest surprises (especially when testing components that use portals) and it allows people to use screen.*
which is all the queries scoped to document.body
.
So while I think it's great that events are now attached to the root, I don't think that will change anything in React Testing Library. We ended up with a better solution anyway :)
from react-testing-library.
@MatanBobi next
points to 17.0.0-rc.0: https://www.npmjs.com/package/react?activeTab=versions
We added experimental
because next
became out of date.
The only change we did for React 17 was dispatching focusin as well when calling fireEvent.focus
. That is in line with how we handle mouseEnter/mouseLeave though not very "vanilla". Ideally people would just use .focus
but that only works with React 17 in jsdom@^16.3.0
so we went with the practical solution.
from react-testing-library.
Alrighty, it looks like the best solution would be to implement this: facebook/react#2043
The latest effort behind it was closed because issues were raised which were never addressed. However, the changes appear fairly minimal and should give anyone who wants to give it a try a head start! Review the discussion in there and open a new PR that addresses those issues.
Anyone want to do that?
from react-testing-library.
It would be cool if we could have a utility that does actual events and also encourage people to just use
.click()
and.focus()
methods native to DOM nodes.
The native click and focus methods do not trigger the DOM side-effects (events) that React and the tested app rely on. Using them contradicts to the core principle of react-testing-library to use the components the same way the users would use them.
Ideally, there has to be a way to simulate real user input followed by its side-effects such as DOM state changes (inputs value/checked/selected, scroll position including overflow, urlbar location, fullscreen API unblock, video play API unblock), DOM events that tell the app about some of these changes, CSS hidden state changes (hover, transition state, animation state) from within the JS platform, but this contradicts to the JS/browser security policy of app sandboxing, thus renders the test automation tools that work from within the JS/browser platform (hi Cypress) helpless about the real user input simulation, leaving them with the hacks like dispatchEvent.
from react-testing-library.
If tests are passing you're probably all good. :-)
I commented on this thread because binding to document was brought up as a limitation.
from react-testing-library.
After further review (and tweets), it appears that this will be a fairly significant effort and perhaps even require a breaking change in React. So we'll have to wait until React 17. Which is unfortunately, but I think it'd be great if we could make this happen in time to get on the React 17 train (whenever that leaves the station...).
from react-testing-library.
Hi @sompylasar,
Thanks for a good overview of the problem. What solutions do you have for us that make attractive trade-offs?
from react-testing-library.
Thanks for a good overview of the problem. What solutions do you have for us that make attractive trade-offs?
Hi @kentcdodds
Unfortunately I don't see a solution from within the browser/JS sandbox. The limited options I see now are:
- the app testing framework implements functions that emulate the browser behavior as close as possible (all the events, bubbling, internal state changes etc), but that still won't match the actual browser behavior with some events, hover, focus, animation, history, media, and so on as no-one can tamper with the browser internal state (please don't tell me not to test it, Cypress);
- the app implementation framework like React limits what's possible to do on the browser platform, especially with positioning, scrolling, focus management, and all things listed above for emulation (this tears the creativity of all the CSS and DOM hackers down to zero which may not be practical in real world apps).
from react-testing-library.
Thanks @sompylasar, I'm afraid that neither of those solutions is reasonable for this project so we'll have to try for the next best thing.
from react-testing-library.
@kentcdodds Just a dumb question here.. I'm just trying to understand the reason behind this idea. Is there any downside of using TestUtils.Simulate
? To me it just actually takes care of Synthetic
events which is what React uses internally. Why do we move away from TestUtils.Simulate
and use dispatchEvent
?
from react-testing-library.
Because Dan said so 🤷♂️ as noted in the first comment.
from react-testing-library.
@kentcdodds Yup, saw the comment from Dan as well.. But was just wondering, why we need to do so.. Is there any benefit for dispatchEvent
or not, I'm not sure. May be we need to ask him in the same twitter thread.
from react-testing-library.
Really awesome progress here: testing-library/dom-testing-library#13 Thanks @jomaxx!!
I'll go ahead and leave this open until that gets released and we update react-testing-library to re-export it.
from react-testing-library.
Thanks to @jomaxx, this was resolved in #48 as well as we can hope for now. It really would be great to get react updated to either remove event delegation entirely or attach event handlers to the root of the react tree rather than the document. For now the solution we have is great though. Thanks!
from react-testing-library.
We're attaching to roots in 17.
https://reactjs.org/blog/2020/08/10/react-v17-rc.html
from react-testing-library.
Our tests are already passing on React 17's RC. Is there anything else we'd need to change to ensure stability in future React 17 releases? Based on my understanding of the blog post I couldn't find any major issues. Is it just extra code for React 16 compatibility?
from react-testing-library.
@nickmccurdy are we sure that's the case? What I remember is that we're running our tests on latest
, next
and experimental
. I think that next
only holds the next minor version.
@gaearon is there a way to know if experimental
tag is based on React 17? Since the version number is based on a hash, I'm not aware of a way to know that..
I may have gotten this wrong, so please @nickmccurdy correct me :)
from react-testing-library.
The only change we did for React 17 was dispatching focusin as well when calling fireEvent.focus
Do you also dispatch focusout for the "left" element?
from react-testing-library.
Do you also dispatch focusout for the "left" element?
No. We also don't dispatch mouseout on fireEvent.mouseEnter
. fireEvent
is only meant as a vanilla event dispatch not for simulating user events. We have a separate package for that.
.focus
really is the best simulation of focus since it also takes care of dispatching blur related events, changing document.activeElement
and checking if the element is even focusable.
Edit: .focus
also makes sure that no focus event is dispatched if the target is already focused.
from react-testing-library.
Related Issues (20)
- TypeScript error with skipLibCheck false HOT 4
- Regression: Types of property `hydrate` are incompatible in `renderHook` options
- Support React 18.3 HOT 2
- act shows up as deprecated when using react 18.3 HOT 1
- Seriously guys, how the fuck do I get started here? HOT 2
- Make @types/react-dom a Peer dependency HOT 2
- TypeScript: unexpected type errors when `exactOptionalPropertyTypes` is enabled
- `ReactDOMTestUtils.act` is deprecated HOT 1
- React does not recognize the `fetchPriority` prop on a DOM element. HOT 3
- Strange behavor when using `renderHook` with `wrapper` option HOT 1
- Hook testing: useReducer doesn't updating state when the reducer action is executed HOT 2
- Bug report
- Issues
- When `container` is `document`, cleanup steps fails with "TypeError: Cannot read properties of null (reading 'removeChild')" HOT 3
- `rerender` does not reset state HOT 6
- Unexpected token 'export' error when running Jest tests with React Native Testing Library HOT 1
- Error test Component with setTimeout and vitest
- Do not want to install react & react-dom dependency in node_modules HOT 1
- Warning: The current testing environment is not configured to support act(...) HOT 4
- RTL + Vitest issue with patching asyncWrapper/eventWrapper (with act()) for userEvent APIs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-testing-library.