add video embeds

kettanaito · kettanaito · commit f0c0de1bb697 · 2025-04-03T19:59:12.000+02:00
diff --git a/exercises/01.sunsetting-jsdom/01.problem.break-jsdom/README.mdx b/exercises/01.sunsetting-jsdom/01.problem.break-jsdom/README.mdx
@@ -1,5 +1,7 @@
 # Break JSDOM
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/sunsetting-jsdom/break-jsdom" />
+
 Before we talk about in-browser component testing, let's start with something familiar.
 
 In this exercise, you have a simple React application that previews the files you upload from your computer. To do that, it has a `type="file"` input and reads the content of the chosen file to display it for the user.
diff --git a/exercises/01.sunsetting-jsdom/01.solution.break-jsdom/README.mdx b/exercises/01.sunsetting-jsdom/01.solution.break-jsdom/README.mdx
@@ -1,5 +1,7 @@
 # Break JSDOM
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/sunsetting-jsdom/break-jsdom/solution" />
+
 I start with rendering the `<FilePreview />` component in my test:
 
 ```tsx add=1,5
diff --git a/exercises/01.sunsetting-jsdom/FINISHED.mdx b/exercises/01.sunsetting-jsdom/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Sunsetting JSDOM
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/sunsetting-jsdom/recap-of-sunsetting-jsdom" />
+
 Great job! 🎉 Have some rest and let's continue.
diff --git a/exercises/01.sunsetting-jsdom/README.mdx b/exercises/01.sunsetting-jsdom/README.mdx
@@ -1,5 +1,7 @@
 # Sunsetting JSDOM
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/sunsetting-jsdom/intro-to-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?
diff --git a/exercises/02.vitest-browser-mode/01.problem.installation-and-setup/README.mdx b/exercises/02.vitest-browser-mode/01.problem.installation-and-setup/README.mdx
@@ -1,5 +1,7 @@
 # Installation and setup
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/installation-and-setup" />
+
 It's time to take the first step forward Vitest Browser Mode! In this one, you and I are going to install all the necessary dependencies so we can start testing our components in the actual browser.
 
 ## Install dependencies
diff --git a/exercises/02.vitest-browser-mode/01.solution.installation-and-setup/README.mdx b/exercises/02.vitest-browser-mode/01.solution.installation-and-setup/README.mdx
@@ -1,5 +1,7 @@
 # Installation and setup
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/installation-and-setup/solution" />
+
 That's it! :tada: You have everything you need to finally start testing your browser code in the browser.
 
 If you try running tests right now, you will get an error:
diff --git a/exercises/02.vitest-browser-mode/02.problem.migrate-the-test/README.mdx b/exercises/02.vitest-browser-mode/02.problem.migrate-the-test/README.mdx
@@ -1,5 +1,7 @@
 # Migrate the test
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/migrate-the-test" />
+
 Since you are migrating your test from running in Node.js to running in the browser, some changes have to be made to your test suites for that to work. Luckily, these changes aren't dramatic, and mostly involve importing the same things from different packages.
 
 > 🦉 The biggest change when adopting Vitest Browser Mode is that it splits the rendering and the UI selection/interaction between two separate packages: `@vitest/browser` and a framework-specific renderer package, like `vitest-browser-react`.
diff --git a/exercises/02.vitest-browser-mode/02.solution.migrate-the-test/README.mdx b/exercises/02.vitest-browser-mode/02.solution.migrate-the-test/README.mdx
@@ -1,5 +1,7 @@
 # Migrate the test
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/migrate-the-test/solution" />
+
 While component tests in Vitest Browser Mode are extremely similar to those you used to write in JSDOM, there are a couple of key differences around component rendering, selecting elements on the page, and writing assertions.
 
 ## Rendering
diff --git a/exercises/02.vitest-browser-mode/03.problem.playwright/README.mdx b/exercises/02.vitest-browser-mode/03.problem.playwright/README.mdx
@@ -1,5 +1,7 @@
 # Playwright
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/playwright" />
+
 The first thing that we can improve is the _browser provider_ used to run our tests. By default, Vitest uses the `preview` provider, which is a great way to get started with the Browser Mode quickly but is not something you would want to use in your application.
 
 The default `preview` provider has a few intentional limitations:
diff --git a/exercises/02.vitest-browser-mode/03.solution.playwright/README.mdx b/exercises/02.vitest-browser-mode/03.solution.playwright/README.mdx
@@ -1,5 +1,7 @@
 # Playwright
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/playwright/solution" />
+
 Let's start by installing `playwright`:
 
 ```sh nonumber
diff --git a/exercises/02.vitest-browser-mode/04.problem.shared-assets/README.mdx b/exercises/02.vitest-browser-mode/04.problem.shared-assets/README.mdx
@@ -1,5 +1,7 @@
 # Shared assets
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/shared-assets" />
+
 Our Vitest is configured and running, but if you take a closer look at the tested component on the page, it seems kind of off:
 
 ![A screenshot of the Vitest UI showing the file preview component missing the styles](/assets/02-04-problem.png)
diff --git a/exercises/02.vitest-browser-mode/04.solution.shared-assets/README.mdx b/exercises/02.vitest-browser-mode/04.solution.shared-assets/README.mdx
@@ -1,5 +1,7 @@
 # Shared assets
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/shared-assets/solution" />
+
 There are two types of test setup you can have: _global_ and _local_. The global setup applies to all tests, while the local one can be introduced on a test suite or a test case basis. I would like to include some shared assets, like styles, to apply to _all_ component tests, which means I need a global setup.
 
 I will start by creating a `vitest.browser.setup.ts` file. The naming here doesn't matter that much, but I like to keep Vitest-related files starting with `vitest.*`.
diff --git a/exercises/02.vitest-browser-mode/05.problem.multiple-workspaces/README.mdx b/exercises/02.vitest-browser-mode/05.problem.multiple-workspaces/README.mdx
@@ -1,5 +1,7 @@
 # Multiple workspaces
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/multiple-workspaces" />
+
 Our current Vitest configuration runs _all tests_ in Browser Mode. This isn't ideal when you need to run different types of tests in the same project - like unit and integration tests running in a Node.js environment alongside browser-based component tests.
 
 You can fix this by introducing _different workspaces_ for different types of tests. In fact, I think this is just the right task for you...
diff --git a/exercises/02.vitest-browser-mode/05.solution.multiple-workspaces/README.mdx b/exercises/02.vitest-browser-mode/05.solution.multiple-workspaces/README.mdx
@@ -1,5 +1,7 @@
 # Multiple workspaces
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/multiple-workspaces/solution" />
+
 Real-world projects often combine multiple types of tests at the same time. Vitest is a great choice for both unit and integration tests, but those two have quite different requirements and, as a result, may need different setups.
 
 Vitest solves this by using _workspaces_.
diff --git a/exercises/02.vitest-browser-mode/FINISHED.mdx b/exercises/02.vitest-browser-mode/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Vitest Browser Mode
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/recap-of-vitest-browser-mode" />
+
 Great job! 🎉 Have a rest and let's continue.
diff --git a/exercises/02.vitest-browser-mode/README.mdx b/exercises/02.vitest-browser-mode/README.mdx
@@ -1,5 +1,7 @@
 # Vitest Browser Mode
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/vitest-browser-mode/intro-to-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 browser-like environment issues becoming more and more problematic, a lot of testing frameworks have invested into designing a component-level testing model:
 
 - [Component testing in Playwright](https://playwright.dev/docs/test-components)
diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx b/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx
@@ -1,4 +1,6 @@
-# Queries
+# Accessibility selectors
+
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/accessibility-selectors" />
 
 One of the primary ways to achieve user-driven tests is to access and interact with the UI elements in the same way the user would. Your users don't know HTML or CSS so they don't locate elements on the page by their class names or `test-id` attributes. Instead, they find the things they need by their _roles_ and _names_ (this is true for visually-impared users as well).
 
diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx b/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx
@@ -1,4 +1,6 @@
-# Queries
+# Accessibility selectors
+
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/accessibility-selectors/solution" />
 
 I'm going to start by locating the discount code input on the page. This one:
 
diff --git a/exercises/03.best-practices/02.problem.user-events/README.mdx b/exercises/03.best-practices/02.problem.user-events/README.mdx
@@ -1,5 +1,7 @@
 # User events
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/user-events" />
+
 How your tests interact with UI elements is just as important as how they locate them. Your users don't dispatch events or programmatically access elements — they hover, click, type, and drag using their input devices.
 
 So, how can we replicate real user interactions in our tests? Historically, integration testing relied on _simulating_ user events, mainly because Node.js can't actually interact with UI elements.
diff --git a/exercises/03.best-practices/02.solution.user-events/README.mdx b/exercises/03.best-practices/02.solution.user-events/README.mdx
@@ -1,5 +1,7 @@
 # User events
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/user-events/solution" />
+
 In its current state, our discount form component test gives you some value, but it can give so much more. We don't create UI elements simply for them "to be" on the page. They are there so our users can interact with them, make them do something, and help them achieve their tasks.
 
 The main purpose of the discount form component is to apply the given discount code. _That_ is what has to be reflected in automated tests.
diff --git a/exercises/03.best-practices/03.problem.network-mocking/README.mdx b/exercises/03.best-practices/03.problem.network-mocking/README.mdx
@@ -1,5 +1,7 @@
 # Network mocking
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/network-mocking" />
+
 So far, our `<DiscountCodeForm />` component has been handling discount codes in a simplified way — just storing them in internal state. In a real application, the component would need to validate and apply these codes through a server, making a _network call_.
 
 In fact, I went and refactored the discount code component to do just that! Now, submitting the form dispatches a `POST https://api.example.com/discount/code` request with the provided code. Only when the server sends back the confirmation will the component display the applied discount in the UI.
diff --git a/exercises/03.best-practices/03.solution.network-mocking/README.mdx b/exercises/03.best-practices/03.solution.network-mocking/README.mdx
@@ -1,5 +1,7 @@
 # Network mocking
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/network-mocking/solution" />
+
 ## Legacy discount scenario
 
 I will start with the legacy discount code scenario.
diff --git a/exercises/03.best-practices/04.problem.element-presence/README.mdx b/exercises/03.best-practices/04.problem.element-presence/README.mdx
@@ -1,5 +1,7 @@
 # Element presence
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/element-presence" />
+
 So far we've covered finding and interacting with elements that are present or will appear on the page. But how do we test for elements that should _not_ render?
 
 This is where you would normally reach for an [inverse assertion](https://www.epicweb.dev/inverse-assertions) to get a predictable result and guard yourself from false-positive tests:
diff --git a/exercises/03.best-practices/04.solution.element-presence/README.mdx b/exercises/03.best-practices/04.solution.element-presence/README.mdx
@@ -1,5 +1,7 @@
 # Element presence
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/element-presence/solution" />
+
 Let's prepare our `<DiscountCodeForm />` for this test case by doing the following:
 
 ```tsx filename=discount-code-form.test.browser.tsx nonumber highlight=5-6,9-12,15-16
diff --git a/exercises/03.best-practices/05.problem.page-navigation/README.mdx b/exercises/03.best-practices/05.problem.page-navigation/README.mdx
@@ -1,5 +1,7 @@
 # Page navigation
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/page-navigation" />
+
 Components in your application don't exist in a vacuum. They are likely a part of a larger component tree that make up a page that lives at a certain _route_. Whether you are building a Single Page Application, or a Multi-Page Application, or even a Statically Generated Site, you are unlikely to avoid routing.
 
 What interests us from the testing perspective here is that components can _access router data_ and _navigate to other routes_. We have to account for both of these use cases for reliable and resilient tests.
diff --git a/exercises/03.best-practices/05.solution.page-navigation/README.mdx b/exercises/03.best-practices/05.solution.page-navigation/README.mdx
@@ -1,5 +1,7 @@
 # Page navigation
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/page-navigation/solution" />
+
 ## Custom wrapper
 
 Okay, let's start by making sure that router-dependent components can render in isolation. For that, I am going to create a _custom wrapper_ function:
diff --git a/exercises/03.best-practices/FINISHED.mdx b/exercises/03.best-practices/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Best practices
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/recap-of-best-practices" />
+
 Great job! 🎉 Have some rest and let's continue.
diff --git a/exercises/03.best-practices/README.mdx b/exercises/03.best-practices/README.mdx
@@ -1,5 +1,7 @@
 # Best practices
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/best-practices/intro-to-best-practices" />
+
 While tools provide a solid foundation, the most important aspects of testing transcend them. Writing great tests remains _your task_.
 
 In this exercise block, we will go through some of the absolutely essential best practices when it comes to writing integration tests. I've written extensively 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, let's add another layer to your testing expertise by focusing on how to write fantastic integration tests.
diff --git a/exercises/04.debugging/01.problem.dom-snapshots/README.mdx b/exercises/04.debugging/01.problem.dom-snapshots/README.mdx
@@ -1,5 +1,7 @@
 # DOM snapshots
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/dom-snapshots" />
+
 Your component tests consist of two parts:
 
 - A rendered UI;
diff --git a/exercises/04.debugging/01.solution.dom-snapshots/README.mdx b/exercises/04.debugging/01.solution.dom-snapshots/README.mdx
@@ -1,5 +1,7 @@
 # DOM snapshots
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/dom-snapshots/solution" />
+
 I've got two failing tests on my hands, and a good place to start is to isolate the one I'm going to address first:
 
 ```tsx filename=tic-tac-toe.browser.test.tsx
diff --git a/exercises/04.debugging/02.problem.debugger/README.mdx b/exercises/04.debugging/02.problem.debugger/README.mdx
@@ -1,5 +1,7 @@
 # Debugger
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/debugger" />
+
 Let's crank it up a notch. Observing the rendered DOM is useful, but not as much as being able to _step through_ what our test is doing. For that, we are going to need a `debugger`.
 
 In JavaScript, if you place a `debugger` statement anywhere in your code, the engine running that code will pause its execution and let you "look around", then proceed to the next debugger checkpoint, if you have any.
diff --git a/exercises/04.debugging/02.solution.debugger/README.mdx b/exercises/04.debugging/02.solution.debugger/README.mdx
@@ -1,5 +1,7 @@
 # Debugger
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/debugger/solution" />
+
 Using the debugger allows me to step through my test wherever and whenever I need to. However, it would be really helpful to pause after my test marks a cell in the `<TicTacToe />` component. I can do that by placing a `debugger` statement after the corresponding actions in the test:
 
 ```tsx filename=tic-tac-toe.browser.test.tsx nonumber nocopy highlight=5,8,11
diff --git a/exercises/04.debugging/03.problem.breakpoints/README.mdx b/exercises/04.debugging/03.problem.breakpoints/README.mdx
@@ -1,5 +1,7 @@
 # Breakpoints
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/breakpoints" />
+
 Placing a `debugger` statement anywhere in your code or test is not the only way to create a breakpoint. In fact, you might've noticed we have to _modify our test_ to add the `debugger` statement!
 
 That isn't ideal. You can add a breakpoint through your IDE instead:
diff --git a/exercises/04.debugging/03.solution.breakpoints/README.mdx b/exercises/04.debugging/03.solution.breakpoints/README.mdx
@@ -1,5 +1,7 @@
 # Breakpoints
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/breakpoints/solution" />
+
 ## Replacing `debugger` with breakpoints
 
 I will start the first task by removing all of the `debugger` statements from `tic-tac-toe.browser.test.tsx`:
diff --git a/exercises/04.debugging/FINISHED.mdx b/exercises/04.debugging/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Debugging tests
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/recap-of-debugging" />
+
 Great job! 🎉 Have some rest and let's continue.
diff --git a/exercises/04.debugging/README.mdx b/exercises/04.debugging/README.mdx
@@ -1,5 +1,7 @@
 # Debugging tests
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/debugging/intro-to-debugging" />
+
 While we all want our tests to pass, the true value of testing emerges [📜 when they fail](https://www.epicweb.dev/writing-tests-that-fail). A failing test means our safeguards are working - catching bugs and regressions before they reach production. That's exactly what we want.
 
 But nobody likes a failing test, more so if you are tasked with fixing one.
diff --git a/exercises/FINISHED.mdx b/exercises/FINISHED.mdx
@@ -1,3 +1,5 @@
 # React Component Testing with Vitest
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/workshop-outro/react-component-testing-with-vitest-outro" />
+
 Hooray! You're all done! 👏👏
diff --git a/exercises/README.mdx b/exercises/README.mdx
@@ -1,3 +1,5 @@
 # React Component Testing with Vitest
 
+<EpicVideo url="https://www.epicweb.dev/workshops/react-component-testing-with-vitest/workshop-introduction/intro-to-react-component-testing-with-vitest" />
+
 Hi! Welcome to the React Component Testing workshop!
