add exercise block intros

Author: kettanaito

exercises/01.sunsetting-jsdom/FINISHED.mdx

@@ -1 +1,3 @@
 # Sunsetting JSDOM
+
+Great job! 🎉 Take some rest and let's continue.

exercises/01.sunsetting-jsdom/README.mdx

@@ -1 +1,25 @@
 # Sunsetting JSDOM
+
+You came to this workshop to learn a new way of testing your UI components, but before we get anywhere near to that, I want you to understand _why_ this change is needed. The last thing I want you to do is refactor your tests just because I told you to. I want _you_ to understand the flawed reality of browser-like environments by experiencing how they let you down firsthand. By the end of this tiny exercise you won't have any wish to use those environments anymore.
+
+But what are browser-like environments, to start with?
+
+## Browser-like environments
+
+The need to test UI components has been around as long as developers were creating them. First browser automation tools date more than a decade ago and while they were used for end-to-end testing, bringing component-level tests to them has proved inefficient. Such tests were hard to write and maintain, and so developers naturally had to solve this problem.
+
+One of those solutions was JSDOM. It's a library that allows you to manipulate the DOM like you would in a real browser but doesn't require you to actually run one. It achieves that through implementing a bunch of WHATWG HTML APIs and exposing you a familiar interface to work with them.
+
+Due to its simplicity and significantly reduced cost of tests, JSDOM has gain wide adoption for testing UI components in isolation. To this day developers use JSDOM wrapped in test environments like `jest-environment-jsdom` to run their integration tests.
+
+## The problem
+
+If I was to highlight the main problem of browser-like environments it would that they are, by design, one big polyfill. The quality and reliability of your tests then becomes as good as the quality of that polyfill. Sadly, it is often lacking in unapparent ways.
+
+About 15 years ago JSDOM set off to solve the lack of proper tooling for integration tests, but the tools have improved and evolved significantly since then. From Cypress to Playwright and now to component-level tests in Vitest, the browser automation has never been more accessible, performant, and efficient to use. And it's only going to get better from here.
+
+> 📜 If you want to learn more about the dangers of browser-like environments, read [Why I Won't Use JSDOM](https://www.epicweb.dev/why-i-won-t-use-jsdom).
+
+But it's not about being redudant. Browser-like environment pose a serious threat to the quality of your tests, have compatibility issues, and can break valid JavaScript code. This often leads to you wasting your time debugging your test environment instead of developing and testing your apps.
+
+I don't want you to waste your time on that. I want you to write solid tests and you can trust, and good tooling is an essential element of that experience.

exercises/02.vitest-browser-mode/FINISHED.mdx

@@ -1 +1,3 @@
 # Vitest Browser Mode
+
+Great job! 🎉 Take some rest and let's continue.

exercises/02.vitest-browser-mode/README.mdx

@@ -1 +1,39 @@
 # Vitest Browser Mode
+
+[Browser Mode](https://vitest.dev/guide/browser/) is a recent addition to [Vitest](https://vitest.dev/) that allows you to run your tests in the actual browser. With the browser-like environment issues becoming more and more pressing, a lot of testing frameworks have invested into designing a component-level testing model:
+
+- [Component testing in Playwright](https://playwright.dev/docs/test-components)
+- [Cypress component testing](https://docs.cypress.io/app/component-testing/get-started)
+- [WebdriverIO component testing](https://webdriver.io/docs/component-testing/)
+
+Browser Mode is Vitest's answer to this problem.
+
+## How it works
+
+Naturally, if you want to run tests in the browser you need a _browser_. What the Vitest team decided to do is embrace existing browser automation tools like Playwright and WebdriverIO, and implement a `provider` layer on top of them. This means you can now repurpose the same tooling you would use for, say, end-to-end test for integration testing.
+
+The next thing to solve was the _test process_ itself. Different tools run your tests differently. For example, in Playwright your tests are written in Node.js and use the `page` object to interact with the browser page that runs in a different process. On the other hand, tests in Cypress are run within the browser directly.
+
+Vitest Browser Mode is similar to Cypress in this regard, meaning that your browser tests are run in the browser. One important distinction here is that since Vitest relies on Vite to compile tests, it can compile your test suite _in the browser_, enabling features like TypeScript and ESM out of the box. You don't have to write lengthy Jest configurations just to have ESM in your tests anymore 🎉
+
+> This is _incredibly_ powerful. Not only does Vitest reuse your existing Vite config, making your code in production and your code in tests be transformed the same way, you can use its rich plugins system to achieve virtually anything. This makes your testing setup highly customizable.
+
+And, finally, Vitest needs something to _render_ the components. Browser Mode is not specific to any particular front-end framework and presently can render React, Vue, and Svelte components natively. You can also build your custom renderers a bit easier since the rendering actually happens in the DOM.
+
+> 📜 You are most definitely encouraged to explore the documentation for [Vitest Browser Mode](https://main.vitest.dev/guide/browser/).
+
+## Benefits of Vitest Browser Mode
+
+Compared to browser-like environments, Vitest Browser Mode has the following benefits:
+
+- **Browser runtime**. No more polyfills, quirky or missing APIs. Your components that meant to be run in the browser can now be tested in the browser as well.
+- **Performance**. Coming from the previous point, Vitest can rely on the browser directly instead of using custom polyfills for browser APIs that may be unreliable and slow.
+- **Familiarity**. Your browser tests look almost identical to the integration tests with JSDOM that you are used to, making it easier to migrate and introduce in new teams.
+
+There are also a few advantages I find in Vitest Browser Mode when compared to other component-testing approaches:
+
+- **Consistency**. Vitest can use your existing Vite configuration both for your app and for your tests. This means a smaller difference between your production and tested code, which is always a win.
+- **Component rendering model**. Running in the browser, your components can render similarly to how they are rendered in production. Vitest has a more [straighforward rendering flow](https://github.com/vitest-dev/vitest-browser-react/blob/1d6be8ca8d94bb2289b6260886f76a6e527c45f7/src/pure.tsx#L50) compared to [Playwright Component Testing](https://github.com/microsoft/playwright/blob/91f46bb5d057a284ff33def5802aba496033c030/packages/playwright-ct-core/src/mount.ts#L61), where Playwright has to channel the rendering from the test (Node.js) to the browser.
+- **Flexibility**. You can use Vitest for both unit tests, Node.js integration tests, and in-browser integration tests. In fact, Vitest makes that easy to do with the concept of workspaces, which you will get your hands on later in this workshop.
+
+Alright, that's enough details. It's time you put Vitest Browser Mode to work for your tests. Let's go!

exercises/03.best-practices/FINISHED.mdx

@@ -1 +1,3 @@
 # Best practices
+
+Great job! 🎉 Take some rest and let's continue.

exercises/03.best-practices/README.mdx

@@ -1,3 +1,17 @@
 # Best practices
 
-Best practices on writing integration tests.
+Tools are important. But the most important things often transcend tools. Tools can give you a solid foundation but it's still _your task_ to write great tests.
+
+In this exercise block, we will go through some of the absolutely essential best practices when it comes to writing integration tests. I've already spoken a lot about the [true purpose of testing](https://www.epicweb.dev/the-true-purpose-of-testing), [what makes a great test](https://www.epicweb.dev/the-golden-rule-of-assertions), and why you want to [write tests that fail](https://www.epicweb.dev/writing-tests-that-fail). All of those still apply. Today, I would like to add another layer onto the onion of your test quality. Today, let's talk about how to achieve fantastic integration tests.
+
+## What we will cover
+
+There's countless practices, patterns, and pieces of advices when it comes to testing. Some general, others extremely specific. For this block, I've trimmed all of those down to the following topics:
+
+1. **Accessibility selectors**. Write tests that find HTML elements the same way your users find them.
+1. **User events**. Write tests that interact with HTML elements the same way your users do.
+1. **Network mocking**. How to mock network requests in your tests with [Mock Service Worker](https://mswjs.io/).
+1. **Element presence**. How to test elements presence, especially when something must _not_ appear in the UI.
+1. **Page navigation**. Testing page transition (i.e. routing) on the integration level.
+
+If you nail these five, you already establish a strong starting point for the quality of your tests. I think it's time we explored them.

exercises/04.debugging/FINISHED.mdx

@@ -1,3 +1,3 @@
 # Debugging tests
 
-:tada:
+Great job! 🎉 Take some rest and let's continue.