uvu VS jsdom

Last but not least important are ava, uvu and tape; they are a really light and fast test runners.

Vitest: A Vite-native unit test framework. (alternative: Jest, uvu)

Most important here is not to forget to include test.run() at the end… I’ve done that a few times 😅. Notice how we are able to use aliases in lines 1–3. You can see the full range of assert methods available in the uvu docs.

For the past few weeks I’ve taken the (arguably pointless) work of migrating Felte from using Jest to uvu. This is a really tedious work by itself, but one of details that would have made this work even more tedious is that Jest prefers assertions to the style of expect(…).toBe* while uvu gives you freedom to choose any assertion library, although there’s an official uvu/assert module that comes with assertions to the style of assert.is(value, expected).

Hello everyone, I'm using uvu for testing. And installed c8 for coverage. Yet it doesn't seem to be able to pick up test .svelte files. Does anyone knows how to achieve this or any other way of getting .svelte files coverage? Thanks

Yes! There’s even an example test written for the svelte counter demo in the repo’s examples!

uvu is what I’d recommend.

I really enjoy Ava [1] or anything assert-tape-like [2]. "uvu" [3] is getting a lot of love lately, but it's very feature limited and much of it's touted advantages are at the detriment to feature set.

[1] https://github.com/avajs/ava

[2] https://github.com/substack/tape

[3] https://github.com/lukeed/uvu

Jest is great for front-end (or full stack integration) testing, but I feel it's specialized for that use-case and doesn't always play nice with backend/middle-tier testing needs.

For Node, I lean towards UVU by @lukeed due to its simplicity. Its lightweight, fast, supports ESM out of the box. It feels like an easier to setup modern Mocha (without the wide array of plugins).

If you happen to be using React Testing Library in your project, you'll need to keep the jsdom dev dependency installed.

Readability.js requires a DOM object to parse the readable content from a website. That's why we create a DOM object with JSDOM and provide the HTML from the page and its current URL. By the way, the browser may have had to follow HTTP redirects, so the current URL doesn't necessarily have to be the one we provided initially. The parse function of the library returns the following result:

This was the basic usage of JSDOM. If you want to learn more, please check out this documentation.

Web scraping, while immensely useful, often requires developers to navigate a sea of tools and libraries, each with its own quirks and intricacies. Whether it's JSDOM, Cheerio, Playwright, or even just plain old vanilla JS in the DevTools console, moving between these platforms can be a challenge.

React testing library uses jsdom (or others like happy-dom) under the hood to emulate the browser environment and enable testing of different properties. but it doesn't render the component in an actual browser meaning the styles can't be computed and the returned computed style is just an object with the correct keys but empty strings as values.

Note: In order to use the library jsdom to scrape the HTML response we need to avoid the @import statements in the CSS.

The code uses jSDom to render the app but I was wondering if it's possible to run the app without the UI to be able to use a library like that to generate the string from react element.

JSDOM as the DOM environment for running our tests