diff --git a/exercises/01.sunsetting-jsdom/FINISHED.mdx b/exercises/01.sunsetting-jsdom/FINISHED.mdx index b8d4398..db89009 100644 --- a/exercises/01.sunsetting-jsdom/FINISHED.mdx +++ b/exercises/01.sunsetting-jsdom/FINISHED.mdx @@ -1,3 +1,3 @@ # Sunsetting JSDOM -Great job! πŸŽ‰ Take some rest and let's continue. +Great job! πŸŽ‰ Have some rest and let's continue. 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 791eb08..729774f 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 @@ -26,12 +26,12 @@ Once you do all this, you will spot that the `*.css` imports fail to resolve in Cannot find module './src/index.css' or its corresponding type declarations.ts(2307) ``` -🐨 To fix this, we need to pull some of the Vite built-in type definitions to help us. At the top of the `vitest.browser.setup.ts` file, add the following type reference comment: +🐨 To fix this, we need to pull in some of the Vite built-in type definitions to help us. At the top of the `vitest.browser.setup.ts` file, add the following type reference comment: ```ts nonumber /// ``` -Lastly, provide the path to the setup file in `vite.config.ts` as the `setupFiles` value of a conrete browser instance (follow the instructions in the configuration file for more details). +Lastly, provide the path to the setup file in `vite.config.ts` as the `setupFiles` value of a concrete browser instance (follow the instructions in the configuration file for more details). Once you have it ready, run the tests again to see the `` component reclaim its striking visuals ✨. 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 0495cca..c15dcc7 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 @@ -4,7 +4,7 @@ There are two types of test setup you can have: _global_ and _local_. The global 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.*`. -In that file, I will import the assets I want to apply to all rendered components: +In that file, I will import the assets I want to include when rendering any component: ```ts filename=vitest.browser.setup.ts add=1 import './src/index.css' 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 2e446da..4f5ee3c 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,14 +1,14 @@ # Multiple workspaces -The way you have Vitest configured right now will run _all tests_ using the Browser Mode. This may be not what you want, especially if you are using Vitest for unit testing or integration testing in Node.js in the same project that needs in-browser component tests as well. +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 differnt types of tests. In fact, I think this is just the right task for you... +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... -πŸ‘¨β€πŸ’Ό In this one, you will expand on the Vitest configuration to support running multiple types of tests in the same project. This will be a multi-step process to make sure you have the Vitest and TypeScript configured correctly for your tests. +πŸ‘¨β€πŸ’Ό In this one, you will expand the Vitest configuration to support running multiple types of tests in the same project. This will be a multi-step process to make sure you have Vitest and TypeScript configured correctly for your tests. -🐨 First, update `vite.config.ts` to list multiple [workspaces](https://main.vitest.dev/guide/workspace.html#configuration). Define one for unit tests and the other for component tests. +🐨 First, update `vite.config.ts` to list multiple [workspaces](https://main.vitest.dev/guide/workspace.html#configuration). Define one for unit tests and another for component tests. -🐨 Next, rename `tsconfig.test.json` to `tsconfig.test.browser.json`. This TypeScript configuration will apply only to the component tests now. Update its `include` to target `**/*.browser.test.ts*` files: +🐨 Next, rename `tsconfig.test.json` to `tsconfig.test.browser.json`. This TypeScript configuration will only apply to the component tests now. Update its `include` setting to target `**/*.browser.test.ts*` files: ```json filename=tsconfig.test.browser.json remove=2 add=3 { @@ -17,7 +17,7 @@ You can fix this by introducing _different workspaces_ for differnt types of tes } ``` -🐨 To have proper type-checking in unit tests, create a new `tsconfig.test.unit.json` file and list there the properties necessary for the unit tests. You can use this as an example: +🐨 To have proper type-checking in unit tests, create a new `tsconfig.test.unit.json` file and add the necessary properties for unit tests. You can use this as an example: ```json filename=tsconfig.test.unit.json { @@ -49,6 +49,6 @@ You can fix this by introducing _different workspaces_ for differnt types of tes } ``` -🐨 Finally, rename the existing `file-preview.test.tsx` component test to `file-preview.browser.test.tsx` to be picked up by the proper workspace in Vitest. +🐨 Finally, rename the existing `file-preview.test.tsx` component test to `file-preview.browser.test.tsx` to be included in the correct Vitest workspace. See you on the other side once you're done to go through each step in more detail. 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 3dac0e1..9320e5b 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 @@ -75,7 +75,7 @@ The first workspace include the configuration for running unit tests: - `exclude` does the opposite of `include`, listing the file patterns to _ignore_. Since my browser tests also end with `*.test.ts`, I need to exclude them not to be confused with unit tests; - `environment` controls the test environment used for this workspace. I want my unit tests to run in Node.js, so I provide `'node'` as the enivornment here. -> :owl: Notice that each workspace lists Vitest configuration starting from the root (e.g. includes the `test` key again). This is handy because this means each workspace can have a different set of Vite options to handle the test files (e.g. list different `plugins`). +> :owl: Notice that each workspace lists Vitest configuration starting from the root by including the `test` key again. This is handy because each workspace can have a different set of Vite options and `plugins` for different test files. Similarly, here's the workspace for the browser (component) tests: @@ -99,17 +99,17 @@ Similarly, here's the workspace for the browser (component) tests: }, ``` -Here, I'm naming this workspace `'browser'` and configuring it to include only `*.browser.test.ts(x)` test files. Those will be my component tests. For the rest of it, I simply moved the existing `test.browser` configuration under this workspace and left it as-is. +Here, I'm naming this workspace `'browser'` and configuring it to include only `*.browser.test.ts(x)` test files. These will be my component tests. For the rest of the configuration, I simply moved the existing `test.browser` configuration under this workspace and left it as-is. ## TypeScript -The next step is to deal with TypeScript. One of the most overlooked aspects of using TypeScript is that you often need _multiple configurations_ within the same project. Your source code, unit tests, integration tests, or test utilities are all written in TypeScript but have different concerns that may require different types. +The next step is to deal with TypeScript. One of the most overlooked aspects of using TypeScript is that you often need _multiple configurations_ within the same project. Your source code, unit tests, integration tests, and test utilities are all written in TypeScript but have different concerns that may require different types. > :scroll: If you want to dive deeper into the reason behing using multiple TypeScript configurations and how to do that properly, read my post called [One Thing Nobody Explained To You About TypeScript](https://kettanaito.com/blog/one-thing-nobody-explained-to-you-about-typescript). -In our project, unit and component tests have a different set of type requirements because they run in different environments. This means I need to introduce two separate configurations: `tsconfig.test.unit.json` and `tsconfig.test.browser.json` to address those differences. +In our project, unit and component tests have a different set of type requirements because they run in different environments. This means I need to introduce two separate configurations to address these differences: `tsconfig.test.unit.json` and `tsconfig.test.browser.json`. -Let's start with the unit tests. +Let's start with the unit tests: ```json filename=tsconfig.test.unit.json { @@ -130,7 +130,7 @@ Similar to how I've configured Vitest workspaces to apply only to specific file "types": ["node", "vitest/globals"] ``` -This include Node.js type definitions (`@types/node`) and Vitest global types (e.g. `test` and `expect`) for my unit tests. Since I don't have the Node.js types installed, I need to add them as a dependency to the project: +This includes Node.js type definitions (`@types/node`) and Vitest global types (e.g. `test` and `expect`) for my unit tests. Since I don't have the Node.js types installed, I need to add them as a dependency to the project: ```sh nonumber npm i -D @types/node @@ -152,7 +152,7 @@ Next, I rename the existing `tsconfig.test.json` to `tsconfig.test.browser.json` ## Test commands -To make it easier to run specific types of tests, I will modify `package.json` to include the new `test:unit` and `test:integration` commands: +To make it easier to run specific types of tests, I will modify `package.json` to add `test:unit` and `test:integration` commands: ```json { @@ -171,4 +171,4 @@ There are multiple ways to group different types of tests in the same project: - **By file name**. This is the one I'm using this exercise, adopting `*.test.ts` for unit tests and `*.browser.test.tsx` for integration tests; - **By directory name**. For example, you can keep unit tests in `./src` while integration tests in `./tests` -The only wrong choice here is the one not followed consistently. You can choose whichever approach makes more sense in your circumstance, but I don't recommend mixing them in the same app. +The choice is up to you β€” I only recommend you stick to one approach and don't mix them in your app. diff --git a/exercises/02.vitest-browser-mode/FINISHED.mdx b/exercises/02.vitest-browser-mode/FINISHED.mdx index 532c7da..d38edbc 100644 --- a/exercises/02.vitest-browser-mode/FINISHED.mdx +++ b/exercises/02.vitest-browser-mode/FINISHED.mdx @@ -1,3 +1,3 @@ # Vitest Browser Mode -Great job! πŸŽ‰ Take some rest and let's continue. +Great job! πŸŽ‰ Have a rest and let's continue. diff --git a/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx b/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx index fa7bd84..97cbe49 100644 --- a/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx +++ b/exercises/03.best-practices/01.problem.accessibility-selectors/README.mdx @@ -1,10 +1,10 @@ # Queries -One of the primary ways to achieve user-driven tests is to access and interact with the UI elements in the same manner 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). +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. -When testing, do what users do. +When testing, do what your users would do. πŸ‘¨β€πŸ’Ό In this exercise, your task is to write a simple integration test for a new React component called -``. And what do you know itβ€”this component is a _form_! This means plenty of elements for you to locate. Use locators like `.getByRole()` and `.getByLabelText()`, and write assertions that make sure all the necessary form elements are present on the page. +``. And what do you knowβ€”this component is a _form_! This means plenty of elements for you to locate. Use locators like `.getByRole()` and `.getByLabelText()`, and write assertions that make sure all the necessary form elements are present on the page. diff --git a/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx b/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx index e6e7b94..d4d5343 100644 --- a/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx +++ b/exercises/03.best-practices/01.solution.accessibility-selectors/README.mdx @@ -17,7 +17,7 @@ I'm going to start by locating the discount code input on the page. This one: /> ``` -A user would find this input by its _label text_ because they would see that it says "Discount code" above that input. When creating the `` component, I've made sure to have an accessible layout by associating a `label` element with the input by its `id`: +A user would find this input by its _label text_ because they would see that it says "Discount code" above that input. When creating the `` component, I've made sure to have accessible markup by associating a `label` element with the input by its `id`: ```tsx filename=discount-code-form.tsx highlight=2,8