Using Vitest Environments

[00:00:00]
>> Cool, so let's actually go into that counter. And let's go ahead and [SOUND]. This one will most likely blow up cuz I have not brought in any DOM. Let's actually see that in practice. So we'll go into src/examples/counter. And we'll do, let's go ahead and go into this counter, and let's go ahead, aspire to be as easy as render(< Counter />).

[00:00:43]
If you do like an npm start, you can see the counter and all the other demo apps on one page, to verify my sanity. It looks like it has an Increment button, it has a Reset button. It has the current count since the last catastrophe, which at the time was just something I thought was funny before I literally had a catastrophe earlier today.

[00:00:58]
So I would hit that Reset button to zero, if I was being intellectually honest with myself, right? And so we can go ahead, we'll do npm run build, no, npm test. Cool. In this case, it fails and we actually want not just the solution one. We'll see why that fails in a second.

[00:01:22]
That is intentional. In this folder we'll do counter.test. All right, cool. It skipped, so that's why it doesn't blow up. Now it blows up. Document is not defined. Few ways I can do this, I can do that like //@vitest-environment. Let's do happy-dom. And now it passes, right? Because all it does is it puts basically a global document object and a window object and spec compliant implementations of everything that you would have in the browser.

[00:02:04]
So you could theoretically, I believe, let's see. I could do, I believe, screen.debug(document.body). Let's rerun, let's do a --run a second. Yeah, not a lot to see here. There's a body element in the document, for document.body. The lighter document will have everything on there. But if one was to, let's go ahead, and let's actually say render that counter again.

[00:02:53]
You can now see that that React counter is rendered to that document.body. And you'll notice that that is not React, that's why you got the regular word class, you don't have any on-click handlers. This is literally a serialization of the actual DOM itself. So this is great when we talked about one of the value props of component testing is that we're using this stuff as our users would.

[00:03:20]
As far as my test is concerned, yeah, I'm rendering a React component. This could be a Vue component. This could be just regular index.html and let it parse. This could be whatever you want it to be. And it doesn't matter. So one of the things we talked about early in the workshop was maybe you would like to migrate from Backbone to React, right?

[00:03:48]
You could, unit tests are not gonna get you there, cuz unit tests are very closely tied to the implementation. You could write a ton of unit tests, and you will throw them all away when you throw away that implementation. Other than the actual rendering of this counter, which you could probably abstract and be clever with.

[00:04:04]
You can basically, this is gonna be regular DOM. So as long as these tests pass, you just kinda swap it out to like mount, whatever the counter says, other way, and obviously, the browser based tests even more. And it's from the user's perspective of JC Dom. We will start to click it as a user and stuff along those lines.

[00:04:20]
And those are more kind of resilient to changes. You can refactor all sorts of stuff and it doesn't really matter because as long as I click the button, and it increments, we're good to go. Like I said, the fact that this doesn't blow up means that the test passes.

[00:04:37]
Which honestly, like I said before, there are tests that I don't keep in the final result that I like as sanity checks, right? I like them to just be like, is my test suite even working, right? A lot of times I have a VS Code snippet, which is like test whatever, expect true to be true.

[00:04:55]
Am I even running the test file that I think I'm running? [LAUGH] Little stuff like that. Cuz maybe you're better than me, but I have lost afternoons to stupider things.