Can't get react-collapse to <UnmountClosed /> in ONLY test with jsdom

[VasilyShelkov]

Context: One of the big reasons I wanted to use <UnmountClosed /> is because it allows me to test that elements aren't showing up in the page anymore via testing in my project.

Problem: When I try to close <UnmountClosed /> in a test using ReactTestingLibrary, it does not unmount as I'd expect. It does behave as expected in the browser.

CodeSandbox: https://codesandbox.io/s/react-collapse-not-unmounting-in-test-7j66r

Observations: The collapse element is style="height: 0px; overflow: hidden;" which suggests to me that it is being collapsed as expected, however, for some reason it isn't resting as expected to unmount in the test only.

Any help is appreciated in advance.

[nkbt]

Not sure how you test it but it actually unmounts everything as expected in your own example:

[VasilyShelkov]

Yup, sorry I probably wasn't clear enough in my issue, It 100% works in the browser as expected, but it doesn't work in the tests.

If you check the tests tab in the codesandbox, there's a single test with comments for extra context and it's unexpectedly failing

[nkbt]

I have no idea what @testing-library does. For any animation related testing I highly recommend doing some sort of proper in browser tests in puppeteer or cypress

[nkbt]

Also you can try to put some timeouts. Larger then one in collapse to check if it is collapsed. Not sure if it will help

Ideally if you unit test you need to exclude 3rd party by mocking them out, otherwise you write tests for that lib and not your own code

[VasilyShelkov]

AFAIK, @testing-library is just a thin wrapper around dom elements from jsdom so is as close as you can get today to the actual dom in unit tests.

For any animation related testing I highly recommend doing some sort of proper in browser tests in puppeteer or cypress

I am not doing any animated related testing, I just wanted to have confidence that elements are or are not appearing on the page depending on the state of the <UnmountClosed />. I appreciate the advice to use something like puppeteer or cypress, but that isn't an option to introduce it in my current project just for this 1 test.

Also you can try to put some timeouts.

The codesandbox already has "timeout" like testing which is commented out on the last line: await waitForElementToBeRemoved(() => queryByText(...)) which will retry and error if by the timeout of jest the element isn't removed from the dom. The result is the same, as I mentioned, you can see by the style attributes that it is collapsed, it's just not unmounting for some reason, I assume it's because an event isn't triggering properly in the implementation which I was hoping to get some help with.

Ideally if you unit test you need to exclude 3rd party by mocking them out, otherwise you write tests for that lib and not your own code

I agree that it's a trade off that I'm sort of retesting the library's functionality, but to me it's worth it because what I'm testing is that my integration of the library works correctly. To me this is valuable in increasing my confidence in how the user would use my implementation of this library. In case you or anyone else is interested in learning more about this "more integration like unit testing". Kent C Dodds has some great resources including @testing-library's guiding principles.

In case anyone else is looking for a workaround: workaround sandbox. I'm now adding this into my tests to check if the collapse is open or closed:

// Check the initial state, in this case the collapse is open
expect(container.querySelector('.ReactCollapse--collapse').style.height).not.toEqual('0px');
expect(container.querySelector('.ReactCollapse--collapse').style.overflow).not.toEqual('hidden');

fireEvent.click(getByText('Collapse control')) // click to control the collapse

// See the style attributes are now closed
expect(container.querySelector('.ReactCollapse--collapse').style.height).toEqual('0px');
expect(container.querySelector('.ReactCollapse--collapse').style.overflow).toEqual('hidden');

This is non-ideal because it's quite brittle according to implementation via the style attributes, but does the job I guess.

I'm happy for the issue to be closed as it would require to do internal debugging which I'm not going to do for now because of the workaround that I figured out. Thanks for replying and helping @nkbt

[nkbt]

There must be some quirk in how jsdom works. It is way to far from the real browsers and I found it very hard to test anything without mocking too much.

Cheers 👍