Use native event dispatching instead of Simulate or SimulateNative

[philipp-spiess]

In #12629 @gaearon suggested that it would be better to drop usage of ReactTestUtils.Simulate and ReactTestUtils.SimulateNative. In this PR I’m attempting at removing it from a lot of places with only a few leftovers.

Those leftovers can be categorized into three groups:

1. Anything that tests that SimulateNative throws. This is a property that native event dispatching doesn’t have so I can’t convert that easily. Affected test suites: EventPluginHub-test, ReactBrowserEventEmitter-test.
2. Anything that tests ReactTestUtils directly. Affected test suites: ReactBrowserEventEmitter-test (this file has one test that reads "should have mouse enter simulated by test utils"), ReactTestUtils-test.
3. Anything that dispatches a change event. The reason here goes a bit deeper and is rooted in the way we shim onChange. Usually when using native event dispatching, you would set the node’s .value and then dispatch the event. However inside inputValueTracking.js we install a setter on the node’s .value that will ignore the next change event (I found this article from Sophie that explains that this is to avoid onChange when updating the value via JavaScript).

All remaining usages of Simulate or SimulateNative can be avoided by mounting the containers inside the document and dispatching native events.

Here some remarks:

1. I’m using Element#click() instead of dispatchEvent. In the jsdom changelog I read that click() now properly sets the correct values (you can also verify it does the same thing by looking at the source).
2. I had to update jsdom in order to get TouchEvent constructors working (and while doing so also updated jest). There was one unexpected surprise: ReactScheduler-test was relying on not having window.performance available. I’ve recreated the previous environment by deleting this property from the global object.
3. I was a bit confused that ReactTestUtils.renderIntoDocument() does not render into the document 🤷‍

[philipp-spiess]

I move this function (which is only used for one test) inside this describe() closure so it's easier to clean up the container.

[gaearon]

I was a bit confused that ReactTestUtils.renderIntoDocument() does not render into the document 🤷‍

You're not alone lol

[gaearon]

We need to be careful with stuff like this because it won't clean up if the test fails. I tend to either use try/finally (annoying) or put it in beforeEach/afterEach.

[gaearon]

Can remove findDOMNode here too. Actually we should remove it in a lot of places in the tests, it's often completely unnecessary and is confusing

[philipp-spiess]

You're not alone lol

This behavior seems to be around for 5 years already 🙈 Do we ever want to change that? It doesn't have to confuse people for 5 more years 🙂 (Related issue: #3789)

[philipp-spiess]

@gaearon I made sure all attached elements are also cleaned up even if the test fails and also removed all findDOMNode calls when we already have a DOM node. Can you take another look?

[nhunzaker]

I've ended up writing try/catch/finally in tests that need document attachment as well. I wonder, if this is common enough, if it makes sense to write a standard test command or function that automatically cleans up, maybe something like:

it.dom('does something', (container) => {
  // Test away, knowing that container will get cleaned up
})

I feel like abstractions around testing are brutally hard though.

[philipp-spiess]

@nhunzaker Yea it's hard to strike the balance between tests that are easy to understand/explicit and avoiding lots of boilerplate code. I think using beforeEach/afterEach works well for this especially if we have more than a couple of tests that require a mounted container in a module:

let container
beforeEach(() => {
  container = document.createElement('div');
  document.body.appendChild(container);
});
afterEach(() => {
  document.body.removeChild(container);
  container = null;
});

The try/finally solution is also ok I guess since it's easy to understand what's intended. Your API would reduce the boilerplate but for folks that are not familiar with our test setup it might be a bit too magical.

[gaearon]

Anything that dispatches a change event. The reason here goes a bit deeper and is rooted in the way we shim onChange.

We do have a way to simulate onChange AFAIK. It’s just a bit odd. You have to grab a value setter before it gets shimmed and then use that directly before dispatching an event. It’s how ChangeEventPlugin tests themselves work. It would be good to convert change callsites too.

[gaearon]

Thanks! If you could follow up for change events that would be great.