linkedom VS jsdom

I recently started using linkedom for this and it has been an absolute joy

This looks great. I wonder how it compares to linkedom (repo[1], writeup[2]), which I have found to be fantastic.

[1]: https://github.com/WebReflection/linkedom

[2]: https://webreflection.medium.com/linkedom-a-jsdom-alternativ...

linkedom, fastest, but lacks essential features

Other things to do would be to use linkedom instead of JSDom, look into a better assertion library than assert etc.

Sounds somewhat similar to linkedom[1], which performs nicely.

[1]: https://github.com/WebReflection/linkedom

const renderCard = ({ onSubmit = jest.fn(),}: RenderCardParams = {}) => { return render( Save , );}; it("should invoke onSubmit when form is submitted", async () => { const onSubmit = jest.fn(); window.HTMLFormElement.prototype.submit = () => {}; const { getByText } = renderCard({ onSubmit }); const button = getByText("Save").closest("button"); if (button) { fireEvent.click(button); } await wait(() => expect(onSubmit).toHaveBeenCalled()); }); I am receiving "Error: Not implemented: HTMLFormElement.prototype.submit". I tried the solution mentioned here https://github.com/jsdom/jsdom/issues/1937 , but it did not work. I do not want to silence the errors but implement the test correctly. Thank you.

This project is very interesting. It actually solves the problem of excess CSS the best; it does so by loading your HTML into jsdom, and then querySelector-ing all of the selectors found in your CSS against the emulated DOM. If a selector isn't found in the emulated DOM, UnCSS will not include the CSS rule in its output.

You should probably add a section to the README explaining why this is useful compared to the alternatives. For example, DOMParser which is built into a web browser, or JSDOM which is the most popular and comprehensive Node in-memory DOM implementation.

Due to the complexity of the application I am working on I have decided on using a nested redux container rather than passing an action as a prop down to the child components. However, this has proved to be problematic for unit testing when rendering the OuterContainer with jsdom in combination with mocha, chai and sinon.

Everything you want to do to your test environment such as extends the jest matchers with @testing-library/jest-dom, mock some APIs that’s not implemented in jdom, you can put to config/jest/setupTests.js:

You may have heard of vite, the slim fast dev server that scored an amazing as deserved 98% satisfaction on the state of js survey 2021. It's creators found unit testing too cumbersome and slow and decided to add their own perspective to the task. The result is vitest: it runs a vite server under the hood to transform the code to test as fast as possible, uses an enhanced flavor of chai to have jest-compatible assertions, integrates DOM mocking using jsdom or happy-dom and even the tiny-spy library that was just built as a separate library to allow for easy reuse is small and compatible with jest.

I think jsdom is what you want to look into. https://github.com/jsdom/jsdom

jsdom, full-featured, but slow, the default option in jest

The next consideration I addressed was being able to easily write and run unit tests for vue-uhtml components. Having previously talked about a unit testing approach for Vue.js components, I was keen to apply the principle of “writing tests that assert your component’s public interface”. Before I could even think about writing component tests, I had to pick the most appropriate and well supported tooling. Vue’s documentation on testing and own vue-test-utils package makes this choice a foregone conclusion with Jest as a comprehensive test framework, and using vue-test-util’s wrapper based API to mount components in an isolated jsdom environment. While jsdom has provided a Custom Elements implementation since version 16, other Web Components APIs including Shadow DOM are not supported or reliable enough to be useful.