Component Testing Configuration

[00:00:00]
>> Let's take a look at what this looks like. And so if you look inside src/examples/counter, I've got this counter test, which is kinda showing you what we can put in there. And well, actually, I'll flip over to that in a moment, but look at it here first.

[00:00:20]
It should render the component, right, where we can actually call render and with some JSX component. I have also, I don't think for this one, I think for the next example, have also done it in Svelte. You will have to squint to see the differences. The same is true, this is using something called React Testing Library.

[00:00:44]
React Testing Library is a series of tools, family members include Svelte Testing Library, Angular Testing Library, you see the theme here, right? In fact, they're all mostly based on this thing called DOM Testing Library, right? And as you know, at the end of the day, all Svelte and React do is they render nodes to the DOM, right?

[00:01:04]
Yes, something, something server-side rendering, but generally speaking. And so they're all kind of built into the same framework, and so really, each one is a set of helper methods. So this will apply whether or not you use React. I just decided that doing Vanilla DOM manipulation is tedious.

[00:01:21]
Most of us probably, even if we work in other technologies, we've probably seen enough React to at least grok the general concepts. If we use this test, it will fail. And it will fail with this ReferenceError: document is not defined, which makes sense cuz we're running a node, and node is not a web browser.

[00:01:43]
It is the V8 engine for parsing JavaScript with, if we're getting pedantic, technically, setTimeout and setInterval are not in JavaScript, they are part of the behavior object model, yada, yada, yada. But generally speaking, most of the DOM is not present in node. And so when it looks for document.body, or if you look at the code, yeah, I think it's looking for either document.findbyid("#main") or something along those lines.

[00:02:18]
But there's no document. So regardless of whether it's document.body or looking for a main or root node, it doesn't matter cuz there's no document, which makes sense because by default, vitest, and I believe this is true of jest, runs in node. Why? Because my golden rule of performance, which is true of the cache is true here, is not doing stuff as faster than doing stuff.

[00:02:44]
And so most of the time, not creating in-memory node-based implementation of the DOM API is faster than doing that. So why would it do that if you don't need it? If you need it, then you can do that. And so the kind of two DOM options that we have is happy-dom, which is kind of the new hotness that emulates most of the browser APIs, and is allegedly faster than jsdom.

[00:03:23]
I believe that. I said allegedly, that I feel like undermines it, it's probably faster. And jsdom, which has been around for at least a decade, possibly more, I forget when Dominic wrote it, but it's been around forever and ever and ever, which means that, one, it is probably incredibly well supported.

[00:03:45]
Two, it probably has a bunch of old implementations that make it heavier and bigger than it needs to be, and thereby makes it slower. Someone asked at the beginning of this workshop, are we gonna use happy-dom? Generally speaking, I do use happy-dom. One of the exercises hit one of those, that word mostly, in most of the browser APIs, there was one edge case that broke in happy-dom.

[00:04:11]
And I was like, you know what, if I'm gonna be live coding in front of people, I'm gonna use the more reliable one so I don't flail wildly about something that's not my fault. Cuz those are kind of bugs where there's no reason why it shouldn't work, except for some implementation, just switching out from happy-dom to jsdom made it work.

[00:04:27]
No one wants to watch me do that standing at this podium, so I am using jsdom. I will say that my default is to start with happy-dom for that, it's supposedly faster, cool, I'm into it, right? As we talk, this stuff adds up, it's all about the cycles but also reliability is also important.

[00:04:44]
That said, I'll show you how you can use happy-dom all the time and then for one test opt into jsdom too. But I felt that was slightly confusing as I was teaching, so I didn't. So that's the kinda origin story there. If you put this in the top of any file, and obviously, it could be happy-dom in this case, and the Jest one I think is Jest environment, most of it is all the same.

[00:05:14]
You can opt in for one file, right? And I will show you how you can also use pattern matching to be only for certain kinds of files. So if you go to the top level, vitestconfig.ts, which is why I have to go into those subdirectories. The top level one is everything kind of in its mostly done state and intermediary ones are down below.

[00:05:39]
You will see, and in fact, I'll just show it to you right now and spoil some of the surprise at the end. You can do these environment match globs, which is I have decided that, I don't even think I used this one per se, that if it ends in .ts, we'll just use the node.

[00:06:01]
If it ends in tsx, I will opt into jsdom, right, or if I have the word component in it or something like that. You can choose to do it by file name, you can put in the ones that you need. You can do whatever you want in this case, whatever makes you happiest works for me, and then you will have that DOM implementation.