diff --git a/README.md b/README.md index 9a5a21c..4cb3599 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@
+ 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 index 0a8e341..4b6ff73 100644 --- 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 + + I start with rendering the `` component in my test: ```tsx add=1,5 diff --git a/exercises/01.sunsetting-jsdom/FINISHED.mdx b/exercises/01.sunsetting-jsdom/FINISHED.mdx index db89009..938e829 100644 --- a/exercises/01.sunsetting-jsdom/FINISHED.mdx +++ b/exercises/01.sunsetting-jsdom/FINISHED.mdx @@ -1,3 +1,5 @@ # 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 index 2bedbf5..4f8260d 100644 --- a/exercises/01.sunsetting-jsdom/README.mdx +++ b/exercises/01.sunsetting-jsdom/README.mdx @@ -1,5 +1,7 @@ # 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 index 9a1fc30..4a8f855 100644 --- 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 + + 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 index ed9390f..1c4025e 100644 --- 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 + + 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 index 2b60b11..f9a9620 100644 --- 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 + + 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 index 1610efd..e9496bc 100644 --- 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 + + 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 index e2f1589..23f0ca1 100644 --- 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 + + 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 index 6fee6bc..d219c35 100644 --- 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 + + 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 index 3232116..d82fb56 100644 --- 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 + + 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 index b552fb7..55fd842 100644 --- 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 + + 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 index 30f36f2..e0f107e 100644 --- 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 + + 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 index 9c39b39..d206ca7 100644 --- 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 + + 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 index d38edbc..3cded1a 100644 --- a/exercises/02.vitest-browser-mode/FINISHED.mdx +++ b/exercises/02.vitest-browser-mode/FINISHED.mdx @@ -1,3 +1,5 @@ # 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 index 981e778..0971471 100644 --- a/exercises/02.vitest-browser-mode/README.mdx +++ b/exercises/02.vitest-browser-mode/README.mdx @@ -1,5 +1,7 @@ # 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.queries/README.mdx similarity index 92% rename from exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx rename to exercises/03.best-practices/01.problem.queries/README.mdx index 51449c6..cd615d8 100644 --- a/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx +++ b/exercises/03.best-practices/01.problem.queries/README.mdx @@ -1,5 +1,7 @@ # Queries + + 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). The way you access different elements in tests matters a lot. It can vary from giving you a ton of value and implicit accessibility assurance to forcing you to change your tests all the time because they are riddled with implementation details. diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/index.html b/exercises/03.best-practices/01.problem.queries/index.html similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/index.html rename to exercises/03.best-practices/01.problem.queries/index.html diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/package.json b/exercises/03.best-practices/01.problem.queries/package.json similarity index 86% rename from exercises/03.best-practices/01.problem.accessibility-selectors/package.json rename to exercises/03.best-practices/01.problem.queries/package.json index 9de388e..ae0b746 100644 --- a/exercises/03.best-practices/01.problem.accessibility-selectors/package.json +++ b/exercises/03.best-practices/01.problem.queries/package.json @@ -1,6 +1,6 @@ { "type": "module", - "name": "exercises_03.best-practices_01.problem.accessibility-selectors", + "name": "exercises_03.best-practices_01.problem.queries", "scripts": { "dev": "vite", "test": "vitest", diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/public/vite.svg b/exercises/03.best-practices/01.problem.queries/public/vite.svg similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/public/vite.svg rename to exercises/03.best-practices/01.problem.queries/public/vite.svg diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/app.tsx b/exercises/03.best-practices/01.problem.queries/src/app.tsx similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/app.tsx rename to exercises/03.best-practices/01.problem.queries/src/app.tsx diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/discount-code-form.browser.test.tsx b/exercises/03.best-practices/01.problem.queries/src/discount-code-form.browser.test.tsx similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/discount-code-form.browser.test.tsx rename to exercises/03.best-practices/01.problem.queries/src/discount-code-form.browser.test.tsx diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/discount-code-form.tsx b/exercises/03.best-practices/01.problem.queries/src/discount-code-form.tsx similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/discount-code-form.tsx rename to exercises/03.best-practices/01.problem.queries/src/discount-code-form.tsx diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/index.css b/exercises/03.best-practices/01.problem.queries/src/index.css similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/index.css rename to exercises/03.best-practices/01.problem.queries/src/index.css diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/main.tsx b/exercises/03.best-practices/01.problem.queries/src/main.tsx similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/main.tsx rename to exercises/03.best-practices/01.problem.queries/src/main.tsx diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/src/vite-env.d.ts b/exercises/03.best-practices/01.problem.queries/src/vite-env.d.ts similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/src/vite-env.d.ts rename to exercises/03.best-practices/01.problem.queries/src/vite-env.d.ts diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tailwind.config.ts b/exercises/03.best-practices/01.problem.queries/tailwind.config.ts similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tailwind.config.ts rename to exercises/03.best-practices/01.problem.queries/tailwind.config.ts diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.app.json b/exercises/03.best-practices/01.problem.queries/tsconfig.app.json similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.app.json rename to exercises/03.best-practices/01.problem.queries/tsconfig.app.json diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.base.json b/exercises/03.best-practices/01.problem.queries/tsconfig.base.json similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.base.json rename to exercises/03.best-practices/01.problem.queries/tsconfig.base.json diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.json b/exercises/03.best-practices/01.problem.queries/tsconfig.json similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.json rename to exercises/03.best-practices/01.problem.queries/tsconfig.json diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.node.json b/exercises/03.best-practices/01.problem.queries/tsconfig.node.json similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.node.json rename to exercises/03.best-practices/01.problem.queries/tsconfig.node.json diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.test.browser.json b/exercises/03.best-practices/01.problem.queries/tsconfig.test.browser.json similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/tsconfig.test.browser.json rename to exercises/03.best-practices/01.problem.queries/tsconfig.test.browser.json diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/vite.config.ts b/exercises/03.best-practices/01.problem.queries/vite.config.ts similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/vite.config.ts rename to exercises/03.best-practices/01.problem.queries/vite.config.ts diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/vitest.browser.setup.ts b/exercises/03.best-practices/01.problem.queries/vitest.browser.setup.ts similarity index 100% rename from exercises/03.best-practices/01.problem.accessibility-selectors/vitest.browser.setup.ts rename to exercises/03.best-practices/01.problem.queries/vitest.browser.setup.ts diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx b/exercises/03.best-practices/01.solution.queries/README.mdx similarity index 98% rename from exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx rename to exercises/03.best-practices/01.solution.queries/README.mdx index b807f39..9cb5f9d 100644 --- a/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx +++ b/exercises/03.best-practices/01.solution.queries/README.mdx @@ -1,5 +1,7 @@ # Queries + + I'm going to start by locating the discount code input on the page. This one: ```tsx filename=discount-code-form.tsx highlight=4-12 nocopy nonumber diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/index.html b/exercises/03.best-practices/01.solution.queries/index.html similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/index.html rename to exercises/03.best-practices/01.solution.queries/index.html diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/package.json b/exercises/03.best-practices/01.solution.queries/package.json similarity index 86% rename from exercises/03.best-practices/01.solution.accessibility-selectors/package.json rename to exercises/03.best-practices/01.solution.queries/package.json index 9221aef..8612bee 100644 --- a/exercises/03.best-practices/01.solution.accessibility-selectors/package.json +++ b/exercises/03.best-practices/01.solution.queries/package.json @@ -1,6 +1,6 @@ { "type": "module", - "name": "exercises_03.best-practices_01.solution.accessibility-selectors", + "name": "exercises_03.best-practices_01.solution.queries", "scripts": { "dev": "vite", "test": "vitest", diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/public/vite.svg b/exercises/03.best-practices/01.solution.queries/public/vite.svg similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/public/vite.svg rename to exercises/03.best-practices/01.solution.queries/public/vite.svg diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/app.tsx b/exercises/03.best-practices/01.solution.queries/src/app.tsx similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/app.tsx rename to exercises/03.best-practices/01.solution.queries/src/app.tsx diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/discount-code-form.browser.test.tsx b/exercises/03.best-practices/01.solution.queries/src/discount-code-form.browser.test.tsx similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/discount-code-form.browser.test.tsx rename to exercises/03.best-practices/01.solution.queries/src/discount-code-form.browser.test.tsx diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/discount-code-form.tsx b/exercises/03.best-practices/01.solution.queries/src/discount-code-form.tsx similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/discount-code-form.tsx rename to exercises/03.best-practices/01.solution.queries/src/discount-code-form.tsx diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/index.css b/exercises/03.best-practices/01.solution.queries/src/index.css similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/index.css rename to exercises/03.best-practices/01.solution.queries/src/index.css diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/main.tsx b/exercises/03.best-practices/01.solution.queries/src/main.tsx similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/main.tsx rename to exercises/03.best-practices/01.solution.queries/src/main.tsx diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/src/vite-env.d.ts b/exercises/03.best-practices/01.solution.queries/src/vite-env.d.ts similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/src/vite-env.d.ts rename to exercises/03.best-practices/01.solution.queries/src/vite-env.d.ts diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tailwind.config.ts b/exercises/03.best-practices/01.solution.queries/tailwind.config.ts similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tailwind.config.ts rename to exercises/03.best-practices/01.solution.queries/tailwind.config.ts diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.app.json b/exercises/03.best-practices/01.solution.queries/tsconfig.app.json similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.app.json rename to exercises/03.best-practices/01.solution.queries/tsconfig.app.json diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.base.json b/exercises/03.best-practices/01.solution.queries/tsconfig.base.json similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.base.json rename to exercises/03.best-practices/01.solution.queries/tsconfig.base.json diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.json b/exercises/03.best-practices/01.solution.queries/tsconfig.json similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.json rename to exercises/03.best-practices/01.solution.queries/tsconfig.json diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.node.json b/exercises/03.best-practices/01.solution.queries/tsconfig.node.json similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.node.json rename to exercises/03.best-practices/01.solution.queries/tsconfig.node.json diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.test.browser.json b/exercises/03.best-practices/01.solution.queries/tsconfig.test.browser.json similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/tsconfig.test.browser.json rename to exercises/03.best-practices/01.solution.queries/tsconfig.test.browser.json diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/vite.config.ts b/exercises/03.best-practices/01.solution.queries/vite.config.ts similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/vite.config.ts rename to exercises/03.best-practices/01.solution.queries/vite.config.ts diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/vitest.browser.setup.ts b/exercises/03.best-practices/01.solution.queries/vitest.browser.setup.ts similarity index 100% rename from exercises/03.best-practices/01.solution.accessibility-selectors/vitest.browser.setup.ts rename to exercises/03.best-practices/01.solution.queries/vitest.browser.setup.ts diff --git a/exercises/03.best-practices/02.problem.user-events/README.mdx b/exercises/03.best-practices/02.problem.user-events/README.mdx index 2dad689..3bd83f6 100644 --- 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 + + 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 index 76bf405..796b86b 100644 --- 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 + + 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 index 4ef52ad..5f30b3b 100644 --- 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 + + So far, our `` 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 index ed4973c..c58ad43 100644 --- 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 + + ## 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 index f691a62..cc9cada 100644 --- 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 + + 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 index e2fc1cd..4a8494b 100644 --- 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 + + Let's prepare our `` 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 index a4b030d..858d53a 100644 --- 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 + + 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 index f84670f..3d3aaeb 100644 --- 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 + + ## 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 index fb0870a..e3a9121 100644 --- a/exercises/03.best-practices/FINISHED.mdx +++ b/exercises/03.best-practices/FINISHED.mdx @@ -1,3 +1,5 @@ # 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 index 4dd13b8..b4ae7ba 100644 --- a/exercises/03.best-practices/README.mdx +++ b/exercises/03.best-practices/README.mdx @@ -1,5 +1,7 @@ # 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. @@ -8,7 +10,7 @@ In this exercise block, we will go through some of the absolutely essential best There are countless practices, patterns, and tips when it comes to testing. Some general, others extremely specific. For this block, I've trimmed all of these down to the following topics: -1. **Accessibility selectors**. Write tests that find HTML elements the same way your users find them. +1. **Queries**. 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. diff --git a/exercises/04.debugging/01.problem.dom-snapshots/README.mdx b/exercises/04.debugging/01.problem.dom-snapshots/README.mdx index fa192c7..457325a 100644 --- 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 + + 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 index d693224..bb95437 100644 --- 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 + + 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 index b3facf5..68a7538 100644 --- a/exercises/04.debugging/02.problem.debugger/README.mdx +++ b/exercises/04.debugging/02.problem.debugger/README.mdx @@ -1,5 +1,7 @@ # 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 index e1707aa..6900a6c 100644 --- a/exercises/04.debugging/02.solution.debugger/README.mdx +++ b/exercises/04.debugging/02.solution.debugger/README.mdx @@ -1,5 +1,7 @@ # Debugger + + 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 `` 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 index 888bb2d..347c75c 100644 --- a/exercises/04.debugging/03.problem.breakpoints/README.mdx +++ b/exercises/04.debugging/03.problem.breakpoints/README.mdx @@ -1,5 +1,7 @@ # 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 index ae2b5d2..89f973d 100644 --- a/exercises/04.debugging/03.solution.breakpoints/README.mdx +++ b/exercises/04.debugging/03.solution.breakpoints/README.mdx @@ -1,5 +1,7 @@ # Breakpoints + + ## 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 index ffe2569..137938b 100644 --- a/exercises/04.debugging/FINISHED.mdx +++ b/exercises/04.debugging/FINISHED.mdx @@ -1,3 +1,5 @@ # Debugging tests + + Great job! ๐ŸŽ‰ Have some rest and let's continue. diff --git a/exercises/04.debugging/README.mdx b/exercises/04.debugging/README.mdx index 7d678b8..f77e859 100644 --- a/exercises/04.debugging/README.mdx +++ b/exercises/04.debugging/README.mdx @@ -1,5 +1,7 @@ # Debugging tests + + 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 index 457f439..032a70c 100644 --- a/exercises/FINISHED.mdx +++ b/exercises/FINISHED.mdx @@ -1,3 +1,9 @@ # React Component Testing with Vitest -Hooray! You're all done! ๐Ÿ‘๐Ÿ‘ + + +Hooray! You've completed the journey through the realm of the component testing ๐Ÿ‘๐Ÿ‘๐Ÿ‘. + +There is so much value to be had from your React component tests. And now, you can finally have it all. Both the ergonomic, familiar API that Vitest provides and the reliability of the actual browser environment under the hood. + +I cannot wait to see the tests you will write now! diff --git a/exercises/README.mdx b/exercises/README.mdx index a7a9f2e..10de60d 100644 --- a/exercises/README.mdx +++ b/exercises/README.mdx @@ -1,3 +1,43 @@ # React Component Testing with Vitest -Hi! Welcome to the React Component Testing workshop! + + +Hi! ๐Ÿ‘‹ You've arrived at the React Component Testing workshop. Before you lies a long journey that has an ambitious destinationโ€”to teach you how to test your React components _in the actual browser_. Now, I'm not talking about end-to-end tests you already have and love. No. + +Today, we are diving into _component-level testing_, bringing along new tools and technologies, such as Vitest Browser Mode, as well as revisiting and updating some of the best practices around React component testing. + +My name is Artem and I've been testing React components for almost a decade now. I've used tools like React Testing Library and JSDOM to help me do that. I trust you've done just the same. Believe me when I say that the Browser Mode in Vitest is a _game-changer_ when it comes to component testing. It's the missing piece that can finally elevate your tests from browser-like environments to the actual browser runtime. This means more reliable, resilient, and useful tests through and through. + +Today marks the day you bring your React component tests to the absolutely new level. + +## Exercises + +Component testing is a vast area of topics and patterns to explore. Whether you're coming to this workshop as someone who has never written a component test before or someone who's got thousands of tests behind them, I've structured this material so it would work for you. + +Let's have an overview of the exercise blocks you will be going through. + +### Sunsetting JSDOM + +You start from the most important partโ€”understanding why you're moving your tests from a browser-like environment (e.g. JSDOM) to the real browser. And you will learn why in the best way possible: by experiencing the shortcomings of browser-like environments firsthand. + +### Vitest Browser Mode + +Next, you will learn how to install, configure, and use Vitest Browser Mode. You will peek behind the scenes and discover the technical difference in how JSDOM and the Browser Mode run your React tests. Equipped with that knowledge, you are going to refactor the component test you wrote earlier from JSDOM to the Browser Mode, and see how your test changes dramatically while, seemingly, not changing at all. + +And as a cherry on top, I will share with you some common setup recipes for efficient component testing, like using different browser automation providers, including shared assets, and using Vitest to its fullest. + +### Best practices + +We simply cannot talk about component testing without going through the best practices. But it won't be a repetition of what you already know because you will explore how moving your tests to the real browser affects those best practices, unlocks new tools for you and deprecates the others you will no longer need. + +You will write tests from the user's perspective, locating elements on the page like your users (or their assistive technology) would do, and interacting with them in the same, implementation-detail-free manner. After that, you will conclude by learning how to set up and use API mocking in your tests, discover how some of the new Vitest APIs make your life easier, and revise the best practices of testing page navigation and routing. + +### Debugging + +In the last exercise block, we will go through what I find to be largely ignored when testing components. _Debugging_. You will apply some of my most favorite techniques of debugging component tests (and components!) both in-browser and right in your IDE. I'll show you how to observe the state of the DOM, stop the JavaScript execution with debugger, and become a time-traveling magician with breakpoints. + +By the end of this block, you will have the tools _and_ confidence to debug any failing component test. + +## Going through the workshop + +As usual, this is an Epic Web workshop, and you will be getting your mind and hands busy with the number of exercises I've tailored for you. I am excited to guide you through this journey and see you learn new things, discover new APIs, and finally get more value out of your component tests. Let's go! diff --git a/tsconfig.json b/tsconfig.json index 921d02a..e883af5 100644 --- a/tsconfig.json +++ b/tsconfig.json @@ -41,10 +41,10 @@ "path": "exercises/02.vitest-browser-mode/05.solution.multiple-workspaces" }, { - "path": "exercises/03.best-practices/01.problem.accessibility-selectors" + "path": "exercises/03.best-practices/01.problem.queries" }, { - "path": "exercises/03.best-practices/01.solution.accessibility-selectors" + "path": "exercises/03.best-practices/01.solution.queries" }, { "path": "exercises/03.best-practices/02.problem.user-events"