add video embeds (#6)

Author: kettanaito

exercises/01.boundaries/01.problem.boundaries/README.mdx

@@ -1,54 +1,5 @@
 # Test boundaries
 
-You will be testing all sorts of code in the wild. Some of it will be simple and self-contained, and some will be tangled with dependencies and side effects. Test boundaries is what helps you to untangle more complex code, focusing on the exact [intention](https://www.epicweb.dev/the-true-purpose-of-testing) you wish to test.
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/boundaries/test-boundaries" />
 
-To help you visualize what mocking does to your tested code I built a little app called [How Mocking Works](https://howmocking.works). Let's explore it together as a part of this exercise.
-
-<callout-info>**You don't have to code anything in this exercise**. There's plenty of coding stored for you later! For now, let's have a proper introduction into mocking with a bit of visual learning.</callout-info>
-
-![How Mocking Works?](https://howmocking.works/og.jpg)
-
-## Mocking visualized
-
-In the app, I represented various JavaScript modules, like `one.js` and `two.js` with geometric shapes, while the dependencies between them with colored lines. The graph that you see represents the extent of the tested code if you are writing a test for the `one.js` module.
-
-By default, _all of the `one.js` dependencies run in the test_. By clicking on the links (lines) between various modules and their methods you can "cut off" (or mock) everything that goes past that link.
-
-The orange double-line injected into the dependency link represents a _mock_. It can be anything, from intercepting an HTTP call to mocking the method or the entire module. Those are the technical details of the mock. No matter what mocking technique you use, it ends up trimming your dependency tree to the scope you need in your test.
-
-## Overmocking
-
-Mocking is a powerful tool. It is crucial you learn from the start that it has to be used sparingly and with a clear purpose. If misused, it can result in tests that don't actually test anything or make your testing experience far more difficult than it has to be.
-
-There are a couple of rules to keep your mocking superpowers at bay:
-
-### Never mock anything directly related to the intention you want to test
-
-If you are testing what happens when the user clicks a button, you mustn't mock that button's behavior. If you do, your test will be testing your mock, and that's not what you want.
-
-> You can reproduce this scenario visually by putting a mock between the `one.js` module and its dependency on the `a()` method. Nothing will be tested if you do!
-
-It may not always be as obvious to determine what's related to the tested intention and what's not. For example, when testing your `Emitter.prototype.emit` method to make sure it calls the previously added listeners, it may be tempting to assume that the listener that's being called is related to the intention.
-
-```ts
-const emitter = new Emitter()
-emitter.on('event', listener)
-emitter.emit('event')
-// Make sure the "listener" function is called!
-```
-
-But the `listener` function itself is not the point. In fact, it can be anything. Its implementation does not influence what you want to test—that _any_ previously added listener gets called when the `event` is emitted.
-
-> :scroll: Follow the [Golden Rule of Assertions](https://www.epicweb.dev/the-golden-rule-of-assertions) to see what influences the result of your test and what doesn't.
-
-### Always mock third-party HTTP calls
-
-No matter the testing level, you must always omit the HTTP calls to _third-party services_ from your test suite. They may seem important but they never are. Your tests can still focus on whether _your application_ performs the necessary requests to those services but their operability must not influence the result of your tests.
-
-> You do not own third-party systems and as such, they mustn't be allowed to affect your test.
-
-### Choose the least intrusive mocking technique possible
-
-In other words, draw the most permissive test boundary that you can.
-
-Coming back to our visual example, if you want to exclude `b()` from the test, mock the `two.js` [dependency on `b()`](https://howmocking.works/#7) and not [the entire `two.js` module](https://howmocking.works/#2). By putting the mock too "high" up the dependency tree, you may lose the important behaviors of your code even if they don't seem related to what you are testing. But most likely, you would end up re-implementing the missing pieces because now _you_ become in charge of the entire `two.js` module.
+I like to start with seemingly basic and straightforward exercises because they end up growing in value as you progress through the material (and beyond). The test boundary is one of such examples. In the end, the entire purpose of mocking is to draw that boundary, and you cannot wield mocking efficiently without understanding it first.

exercises/01.boundaries/01.solution.boundaries/README.mdx

@@ -1,3 +1,56 @@
 # Test boundaries
 
-I like the start topics with seemingly basic and straightforward exercises because they end up growing in value as you progress through the material (and beyond). The test boundary is one of such examples. In the end, the entire purpose of mocking is to draw that boundary, and you cannot wield mocking efficiently without understanding it first.
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/boundaries/test-boundaries/solution" />
+
+You will be testing all sorts of code in the wild. Some of it will be simple and self-contained, and some will be tangled with dependencies and side effects. Test boundaries is what helps you to untangle more complex code, focusing on the exact [intention](https://www.epicweb.dev/the-true-purpose-of-testing) you wish to test.
+
+To help you visualize what mocking does to your tested code I built a little app called [How Mocking Works](https://howmocking.works). Let's explore it together as a part of this exercise.
+
+<callout-info>**You don't have to code anything in this exercise**. There's plenty of coding stored for you later! For now, let's have a proper introduction into mocking with a bit of visual learning.</callout-info>
+
+![How Mocking Works?](https://howmocking.works/og.jpg)
+
+## Mocking visualized
+
+In the app, I represented various JavaScript modules, like `one.js` and `two.js` with geometric shapes, while the dependencies between them with colored lines. The graph that you see represents the extent of the tested code if you are writing a test for the `one.js` module.
+
+By default, _all of the `one.js` dependencies run in the test_. By clicking on the links (lines) between various modules and their methods you can "cut off" (or mock) everything that goes past that link.
+
+The orange double-line injected into the dependency link represents a _mock_. It can be anything, from intercepting an HTTP call to mocking the method or the entire module. Those are the technical details of the mock. No matter what mocking technique you use, it ends up trimming your dependency tree to the scope you need in your test.
+
+## Overmocking
+
+Mocking is a powerful tool. It is crucial you learn from the start that it has to be used sparingly and with a clear purpose. If misused, it can result in tests that don't actually test anything or make your testing experience far more difficult than it has to be.
+
+There are a couple of rules to keep your mocking superpowers at bay:
+
+### Never mock anything directly related to the intention you want to test
+
+If you are testing what happens when the user clicks a button, you mustn't mock that button's behavior. If you do, your test will be testing your mock, and that's not what you want.
+
+> You can reproduce this scenario visually by putting a mock between the `one.js` module and its dependency on the `a()` method. Nothing will be tested if you do!
+
+It may not always be as obvious to determine what's related to the tested intention and what's not. For example, when testing your `Emitter.prototype.emit` method to make sure it calls the previously added listeners, it may be tempting to assume that the listener that's being called is related to the intention.
+
+```ts
+const emitter = new Emitter()
+emitter.on('event', listener)
+emitter.emit('event')
+// Make sure the "listener" function is called!
+```
+
+But the `listener` function itself is not the point. In fact, it can be anything. Its implementation does not influence what you want to test—that _any_ previously added listener gets called when the `event` is emitted.
+
+> :scroll: Follow the [Golden Rule of Assertions](https://www.epicweb.dev/the-golden-rule-of-assertions) to see what influences the result of your test and what doesn't.
+
+### Always mock third-party HTTP calls
+
+No matter the testing level, you must always omit the HTTP calls to _third-party services_ from your test suite. They may seem important but they never are. Your tests can still focus on whether _your application_ performs the necessary requests to those services but their operability must not influence the result of your tests.
+
+> You do not own third-party systems and as such, they mustn't be allowed to affect your test.
+
+### Choose the least intrusive mocking technique possible
+
+In other words, draw the most permissive test boundary that you can.
+
+Coming back to our visual example, if you want to exclude `b()` from the test, mock the `two.js` [dependency on `b()`](https://howmocking.works/#7) and not [the entire `two.js` module](https://howmocking.works/#2). By putting the mock too "high" up the dependency tree, you may lose the important behaviors of your code even if they don't seem related to what you are testing. But most likely, you would end up re-implementing the missing pieces because now _you_ become in charge of the entire `two.js` module.

exercises/01.boundaries/FINISHED.mdx

@@ -1,5 +1,7 @@
 # Boundaries
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/boundaries/recap-of-boundaries" />
+
 Understanding test boundaries helps you think about mocking as a tool. A tool that helps you balance what matters in the test vs what doesn't. That's really what mocking of any kind is about.
 
 Ultimately, it is _your_ decision when to draw that line. Just know that it will affect what kind of test you get in return.

exercises/01.boundaries/README.mdx

@@ -1,5 +1,7 @@
 # Boundaries
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/boundaries/intro-to-boundaries" />
+
 There has been almost two decades since mocks (originally called "_test doubles_") were first defined. If you go and search for "mocks" online right now, you will find a plethora of technical explanations and usage examples on how to substitute, spy, stub, replace, fake, and do all sorts of things with the tested code. Most of those resources put emphasis on different ways to mock but, somehow, seldom bother to explain what _is_ a mock, _when_ would you reach out for one, and _what_ it actually does to your code.
 
 ## What is mocking?

exercises/02.functions/01.problem.mock-functions/README.mdx

@@ -1,5 +1,7 @@
 # Mock functions
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/mock-functions" />
+
 We have an `Emitter` implementation that can add listeners to events and call those listeners whenever a matching event is emitted. This behavior is achieved by implementing two core methods on the emitter: `.on()` and `.emit()`:
 
 <CodeFile file="emitter.ts" range="7-22" nocopy />

exercises/02.functions/01.solution.mock-functions/README.mdx

@@ -1,5 +1,7 @@
 # Mock functions
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/mock-functions/solution" />
+
 In the `emitter.test.ts`, I will start from creating the `listener` function but it won't be a regular JavaScript function. Instead, I will use the `vi.fn()` API from Vitest, which creates a _special_ kind of function.
 
 <CodeFile file="emitter.test.ts" range="5" />

exercises/02.functions/02.problem.spies/README.mdx

@@ -1,5 +1,7 @@
 # Spies
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/spies" />
+
 Testing the intentions around side effects is always tricky. Like this `UserService` class that's supposed to log out the `createUser` event whenever a new user is created:
 
 <CodeFile file="user-service.ts" highlight="7" nocopy />

exercises/02.functions/02.solution.spies/README.mdx

@@ -1,5 +1,7 @@
 # Spies
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/spies/solution" />
+
 Let's start by creating a _spy_ for the `logger.log()` method using the [`vi.spyOn()`](https://vitest.dev/api/vi.html#vi-spyon) function from Vitest:
 
 <CodeFile file="user-service.test.ts" range="5-7" highlight="6" />

exercises/02.functions/03.problem.mock-implementation/README.mdx

@@ -1,5 +1,7 @@
 # Mock implementation
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/mock-implementation" />
+
 In this one, we have an `OrderController` class responsible for handling orders in our eshop. It has a `.createOrder()` method that accepts a `cart` object and does the following:
 
 1. Throws an error if any of the cart items are out of stock;

exercises/02.functions/03.solution.mock-implementation/README.mdx

@@ -1,5 +1,7 @@
 # Mock implementation
 
+<EpicVideo url="https://www.epicweb.dev/workshops/mocking-techniques-in-vitest/functions/mock-implementation/solution" />
+
 Let's start by going to the first test case for our `OrderController` and spying on the `isItemInStock` method of the created `controller` instance:
 
 <CodeFile file="order-controller.test.ts" range="3-6" highlight="6" />