Describe the bug
We have some tests that clicking on React Router Dom links and assert that the window.location.href has been updated accordingly in the test.
When using happy-dom 14.12.0, these tests pass, but with happy-dom 14.12.1 and above, these tests fail.
We could also argue that assertions on the window.location.href globals aren't advisable in any case, and there are alternative ways to test the Link URL / routing change (we can see that the change in the Route by the Link in MemoryRouter of that repo is correctly detected with the assertion expect(await screen.findByText('This should show TODOs')).toBeInTheDocument();, no matter what happy-dom version is being used).
However, it is handy for very small unit tests on components with Links where you don't want to render the full DOM of a Routes app.
And even if we decide not to fix this issue, it would be good to understand where it is originating from and why the change in that PR has caused this.
Describe the bug We have some tests that clicking on React Router Dom links and assert that the
window.location.hrefhas been updated accordingly in the test. When using happy-dom 14.12.0, these tests pass, but with happy-dom 14.12.1 and above, these tests fail.To Reproduce Steps to reproduce the behavior:
npm iandnpm run testin the terminal."happy-dom":"14.12.0"Expected behavior Tests should still pass on latest happy-dom version
Screenshots N/A
Device: N/A
Additional context This issue looks related to https://github.com/capricorn86/happy-dom/pull/1465.
We could also argue that assertions on the
window.location.hrefglobals aren't advisable in any case, and there are alternative ways to test the Link URL / routing change (we can see that the change in the Route by the Link in MemoryRouter of that repo is correctly detected with the assertionexpect(await screen.findByText('This should show TODOs')).toBeInTheDocument();, no matter what happy-dom version is being used). However, it is handy for very small unit tests on components with Links where you don't want to render the full DOM of a Routes app. And even if we decide not to fix this issue, it would be good to understand where it is originating from and why the change in that PR has caused this.Thank you!