Transcript
00:00 Before we begin, let's make sure that we're on the same page when it comes to component testing and browser-like environments in particular. You see, developers had the need to test their browser code for as long as they've been writing it. But browser automation tools were in a quite different state 10, 20, or 30 years ago. Writing that automation was cumbersome,
00:19 and tests that depended on it were often flaky or unreliable. Needless to say, a compromise has to be made. And this is where we saw the rise of browser-like environments, GSDOM being perhaps one of the most prominent ones. In itself, GSDOM is a Node.js library that
00:34 gives you this evaluation context with browser APIs so your code can run there as if it's an actual browser. Of course, no browsers are involved here. That's the whole point. So how does it work? Well, it uses a bunch of polyfills to implement those browser APIs in Node.js,
00:51 things like DOM API, Fetch, or XMLHttpRequest, and so on. And then as far as your test code is concerned, it interfaces with those browser APIs without there being any browser to begin with. Unfortunately, those browser-like environments were and still remain a compromise. And as time
01:08 went on, there were more and more issues around them, and the fact that the Node.js and browser now share more common standard APIs than they ever did before only adds insult to injury. But I'm getting ahead of myself. We will talk in more detail about browser-like environments and why it's a good time to immigrate away from one, but not before you
01:27 complete the first exercise and experience some of their downsides for yourself.