01/02: add exercise texts

kettanaito · kettanaito · commit b37b260c2b69 · 2025-04-22T11:19:50.000+02:00
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/README.mdx b/exercises/01.setup/02.problem.multiple-workspaces/README.mdx
@@ -0,0 +1,27 @@
+# Multiple workspaces
+
+Vitest is an extremely versatile testing framework. You can use it for your unit tests in Node.js, for your integration tests, for component-level testing with the [Browser Mode](https://vitest.dev/guide/browser/), for benchmarking... All within the same tool. But those are still quite different tests and as such, they may require different configurations to run.
+
+You can configure multiple test projects, or [workspaces](https://vitest.dev/guide/workspace.html#defining-a-workspace), within the same repository to help Vitest differentiate between all the layers of testing you have. This is a great way to utilize Vitest to the fullest while implementing a great test coverage.
+
+## Your task
+
+This brings me to the application at hand, which has two testing layers: unit and integration tests. While the unit tests run in a regular Node.js environment, the integration tests are a bit different.
+
+See, our application happened to use _edge functions_ (find them in `src/api`). We still have to test those functions in isolation but that's where a Node.js test won't cut it. Edge environment is fundamentally different from Node.js both in available APIs and behaviors.
+
+So to test our edge functions we are going to use a _custom environment_ called `edge-runtime`. It's modelled after the common runtimes you can find in providers like Vercel or Netlify, and it will allow us to bring our edge functions to a similar habitat as production.
+
+👨‍💼 In this exercise, your goal is to configure Vitest to have two different workspaces: one for the unit tests and another for the edge tests. Start from the instructions below.
+
+🐨 First, install `edge-runtime`, `@edge-runtime/vm`, and `@edge-runtime/types` in your project. You will use these to procure the correct test environment for your edge functions.
+
+```
+npm install edge-runtime @edge-runtime/vm @edge-runtime/types --save-dev
+```
+
+🐨 Next, head to <InlineFile file="vitest.config.ts" /> and complete it to have two different workspaces defined. Use different filename patterns to apply workspaces to their respective tests: `**/*.test.ts` for unit tests and `**/*.edge.test.ts` for the edge tests.
+
+🐨 Once the Vitest is configured, head to the test files at <InlineFile file="src/slugify.test.ts" /> and <InlineFile file="src/api/handler.edge.test.ts" /> and follow the instructions to write a few tests.
+
+And, of course, run `npm test` to verify that all the tests are running in their correct environments and passing. Good luck!
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/global.d.ts b/exercises/01.setup/02.problem.multiple-workspaces/global.d.ts
@@ -0,0 +1,4 @@
+declare module '*?raw' {
+	const src: string
+	export default src
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/package.json b/exercises/01.setup/02.problem.multiple-workspaces/package.json
@@ -0,0 +1,11 @@
+{
+  "type": "module",
+  "name": "exercises_01.setup_02.problem.multiple-workspaces",
+  "scripts": {
+    "test": "vitest",
+    "build": "vite build"
+  },
+  "devDependencies": {
+    "vitest": "^3.1.1"
+  }
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/src/api/handler.edge.test.ts b/exercises/01.setup/02.problem.multiple-workspaces/src/api/handler.edge.test.ts
@@ -0,0 +1,25 @@
+// 🐨 Import the `EdgeRuntime` class from the `edge-runtime` package.
+// 💰 import { EdgeRuntime } from 'edge-runtime
+//
+// 🐨 Import your handler from the `./handler` module.
+// Use a "?raw" import modified to import it as a string.
+// 💰 import initialCode from './handler?raw'
+//
+// 🐨 Declare a new variable called `runtime`.
+// Assign it a new instance of `EdgeRuntime` that uses
+// the `initialCode` as its initial code.
+// 💰 const runtime = new EdgeRuntime({ initialCode })
+//
+// 🐨 Declare a new test case. Here, ensure that your edge
+// runtime handles HTTP requests correctly.
+// 💰 test('...', async () => {})
+//
+// 🐨 Inside the test, call `runtime.dispatchFetch(url)`
+// to perform a request.
+// 💰 const response = await runtime.dispatchFetch(url)
+//
+// 🐨 Finally, add an asynchronous assertion over `request.json()`
+// that validates the received response body against the
+// response returned from the "fetch" event listener in
+// the `./handler` module.
+// 💰 await expect(response.json()).resolves.toEqual(expected)
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/src/api/handler.ts b/exercises/01.setup/02.problem.multiple-workspaces/src/api/handler.ts
@@ -0,0 +1,8 @@
+addEventListener('fetch', (event) => {
+	event.respondWith(
+		Response.json({
+			id: 'abc-123',
+			name: 'John Maverick',
+		}),
+	)
+})
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/src/slugify.test.ts b/exercises/01.setup/02.problem.multiple-workspaces/src/slugify.test.ts
@@ -0,0 +1,7 @@
+import { slugify } from './slugify'
+
+// 🐨 Create a new test case for the `slugify` function`.
+// In this one, ensure that calling that function with a "hello world"
+// as the argument returns the correct slugified string.
+// 💰 test('...', () => {})
+// 💰 expect(actual).toBe(expected)
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/src/slugify.ts b/exercises/01.setup/02.problem.multiple-workspaces/src/slugify.ts
@@ -0,0 +1,3 @@
+export function slugify(input: string): string {
+	return input.replace(/\s+/g, '-')
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.app.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.app.json
@@ -0,0 +1,8 @@
+{
+	"extends": "./tsconfig.base.json",
+	"include": ["src/**/*"],
+	"exclude": ["src/**/*.test.ts"],
+	"compilerOptions": {
+		"lib": ["esnext"]
+	}
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.base.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.base.json
@@ -0,0 +1,23 @@
+{
+	"compilerOptions": {
+		"target": "ESNext",
+		"module": "ESNext",
+		"useDefineForClassFields": true,
+		"skipLibCheck": true,
+
+		/* Bundler mode */
+		"moduleResolution": "bundler",
+		"allowImportingTsExtensions": true,
+		"isolatedModules": true,
+		"moduleDetection": "force",
+		"noEmit": true,
+		"verbatimModuleSyntax": true,
+
+		/* Linting */
+		"strict": true,
+		"noUnusedLocals": false,
+		"noUnusedParameters": false,
+		"noFallthroughCasesInSwitch": true,
+		"noUncheckedSideEffectImports": true
+	}
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.edge.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.edge.json
@@ -0,0 +1,9 @@
+{
+	"extends": "./tsconfig.base.json",
+	"include": ["src/api"],
+	"exclude": ["**/*.test.ts"],
+	"compilerOptions": {
+		"lib": [],
+		"types": ["@types/node", "@edge-runtime/types"]
+	}
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.json
@@ -0,0 +1,10 @@
+{
+	"files": [],
+	"references": [
+		{ "path": "tsconfig.edge.json" },
+		{ "path": "tsconfig.app.json" },
+		{ "path": "tsconfig.node.json" },
+		{ "path": "tsconfig.test.edge.json" },
+		{ "path": "tsconfig.test.json" }
+	]
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.node.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.node.json
@@ -0,0 +1,7 @@
+{
+	"extends": "./tsconfig.base.json",
+	"compilerOptions": {
+		"lib": ["ES2023"]
+	},
+	"include": ["vitest.config.ts"]
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.test.edge.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.test.edge.json
@@ -0,0 +1,8 @@
+{
+	"extends": "./tsconfig.edge.json",
+	"include": ["global.d.ts", "**/*.edge.test.ts"],
+	"exclude": [],
+	"compilerOptions": {
+		"types": ["@types/node", "@edge-runtime/types", "vitest/globals"]
+	}
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.test.json b/exercises/01.setup/02.problem.multiple-workspaces/tsconfig.test.json
@@ -0,0 +1,8 @@
+{
+	"extends": "./tsconfig.app.json",
+	"include": ["src/**/*", "src/**/*.test.ts"],
+	"exclude": [],
+	"compilerOptions": {
+		"types": ["vitest/globals"]
+	}
+}
diff --git a/exercises/01.setup/02.problem.multiple-workspaces/vitest.config.ts b/exercises/01.setup/02.problem.multiple-workspaces/vitest.config.ts
@@ -0,0 +1,23 @@
+import { defineConfig, configDefaults } from 'vitest/config'
+
+export default defineConfig({
+	test: {
+		// 🐨 Add a property called `workspace`.
+		// Assign it an array as a value.
+		// 💰 workspace: []
+		//
+		// 🐨 Add the first object to the `workspace` array.
+		// Inside that object, define a property called `test`.
+		// This will be your configuration for unit tests.
+		// Describe it accordingly, giving it a distinct `name`,
+		// `environment`, and `include` and `exclude` patterns.
+		// 💰 test: { name: 'unit', environment: 'node', globals: true }
+		//
+		// 🐨 Add the second object to the `workspace` array.
+		// Similarly to the first one, this will be your configuration for edge tests.
+		// Give it a `name`, and use `edge-runtime` as its `environment`.
+		// Don't forget to specify the `include` pattern so it applies only
+		// to the "**/*.edge.test.ts" test files.
+		// 💰 test: { name: '...', environment: '...', globals: true }
+	},
+})
diff --git a/exercises/01.setup/02.solution.multiple-workspaces/README.mdx b/exercises/01.setup/02.solution.multiple-workspaces/README.mdx
@@ -1,5 +1,185 @@
 # Multiple workspaces
 
-1. Use `test.workspace` to define a list of workspaces.
-1. Give each workspace a unique `test.name` and `include` pattern. Also, any other configuration, like `environment`.
-1. Run all workspaces via `vitest` or individual workspaces via `vitest --project <WORKSPACE_NAME>`.
+## Defining workspaces
+
+First, I will configure Vitest to have two workspaces.
+
+In `vitest.config.ts`, I will define a `test.workspace` property and assign an empty array as a value to it:
+
+```ts filename=vitest.config.ts add=4-6
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+	test: {
+		workspace: [],
+	},
+})
+```
+
+Each entry in the `test.workspace` array will represent a standalone workspace (or project) that Vitest can run. Projects can have their own configurations, environments, and file patterns to know about the relevant test files.
+
+For example, let's define a workspace configuration for unit tests:
+
+```ts filename=vitest.config.ts highlight=1 add=6-14
+import { defineConfig, configDefaults } from 'vitest/config'
+
+export default defineConfig({
+	test: {
+		workspace: [
+			{
+				test: {
+					name: 'unit',
+					environment: 'node',
+					globals: true,
+					include: ['**/*.test.ts'],
+					exclude: [...configDefaults.exclude, '**/*.edge.test.ts'],
+				},
+			},
+		],
+	},
+})
+```
+
+Here, I am declaring the following:
+
+- The `name` of this workspace will be `'unit`';
+- It will use `node` as the test `environment`;
+- It will have functions like `test()` and `expect()` available globally (`globals: true`);
+- It will only apply to the test files matching the `**/*.test.ts` pattern;
+- And, finally, it will exclude both the default patterns in Vitest (`...configDefaults.exclude`) and the edge test cases (`**/*.edge.test.ts`).
+
+<callout-success>You may notice that this `test` object looks really similar to the root-level `test` you can define in `vitest.config.ts`. That's because it is! Vitest allows you to define an entire test configuration nested under your workspace.</callout-success>
+
+Similarly, I will add a workspace for edge tests:
+
+```ts filename=vitest.config.ts add=15-22
+import { defineConfig, configDefaults } from 'vitest/config'
+
+export default defineConfig({
+	test: {
+		workspace: [
+			{
+				test: {
+					name: 'unit',
+					environment: 'node',
+					globals: true,
+					include: ['**/*.test.ts'],
+					exclude: [...configDefaults.exclude, '**/*.edge.test.ts'],
+				},
+			},
+			{
+				test: {
+					name: 'edge',
+					globals: true,
+					environment: 'edge-runtime',
+					include: ['**/*.edge.test.ts'],
+				},
+			},
+		],
+	},
+})
+```
+
+One notable exception here is that I am using `edge-runtime` as the test environment for my edge tests. This will tap into the `edge-runtime` package we've installed earlier to give a proper test environment for our tests.
+
+With Vitest configured, it is time to add some tests!
+
+## Unit tests
+
+I will head to `src/slugify.test.ts` and write a simple unit test for the `slugify()` utility function:
+
+```ts filename=src/slugify.test.ts add=3-5
+import { slugify } from './slugify'
+
+test('returns a slugified string', () => {
+	expect(slugify('hello world')).toBe('hello-world')
+})
+```
+
+## Edge tests
+
+Now, the test setup for `src/api/handler.edge.test.ts` will be slightly different.
+
+I will start from importing the `EdgeRuntime` class from the `edge-runtime` package:
+
+```ts filename=src/api/handler.edge.test.ts add=1
+import { EdgeRuntime } from 'edge-runtime'
+```
+
+Then, let's get the request handler I need to test from `./handler`:
+
+```ts filename=src/api/handler.edge.test.ts add=2
+import { EdgeRuntime } from 'edge-runtime'
+import initialCode from './handler?raw'
+```
+
+> 🦉 Notice that I am using a `?raw` import modified so that `initialCode` is a _string content of the module_ and not its exports. You will see why in a moment.
+
+And now, I will declare the actual edge runtime that will evaluate and run my handler:
+
+```ts filename=src/api/handler.edge.test.ts add=4-6
+import { EdgeRuntime } from 'edge-runtime'
+import initialCode from './handler?raw'
+
+const runtime = new EdgeRuntime({
+	initialCode,
+})
+```
+
+<callout-info>While the `edge-runtime` test environment ensures that the correct global APIs are available in the test's context (like `window` or `fetch`), the `EdgeRuntime` instance creates an actual controlled runtime that will behave according to my handler (e.g. handle requests).</callout-info>
+
+What remains is a test case where I will fetch some resource and assert that its response equals to that specified in `./handler`:
+
+```ts filename=src/api/handler.edge.test.ts add=8-17
+import { EdgeRuntime } from 'edge-runtime'
+import initialCode from './handler?raw'
+
+const runtime = new EdgeRuntime({
+	initialCode,
+})
+
+test('returns the user by id', async () => {
+	const response = await runtime.dispatchFetch(
+		'https://example.com/users/abc-123',
+	)
+
+	await expect(response.json()).resolves.toEqual({
+		id: 'abc-123',
+		name: 'John Maverick',
+	})
+})
+```
+
+## Running tests
+
+I can run all my tests at once using a single `vitest` command (or `npm test` already defined in the project's `scripts`):
+
+```
+npm test
+
+ ✓  unit  src/slugify.test.ts (1 test) 1ms
+ ✓  edge  src/api/handler.edge.test.ts (1 test) 3ms
+
+ Test Files  2 passed (2)
+      Tests  2 passed (2)
+   Start at  11:17:31
+   Duration  221ms (transform 31ms, setup 0ms, collect 30ms, tests 5ms, environment 16ms, prepare 73ms)
+```
+
+<callout-success>Motice how Vitest prints the workspace name (`unit` and `edge`) next to the respective test files. This lets you know which workspace is handling that file.</callout-success>
+
+But I can also run individual workspaces by providing the `--project` option to the Vitest CLI and giving it the name of the workspace I want to run:
+
+```
+npm test -- --project=edge
+
+ ✓  edge  src/api/handler.edge.test.ts (1 test) 4ms
+   ✓ returns the user by id 3ms
+
+ Test Files  1 passed (1)
+      Tests  1 passed (1)
+   Start at  11:18:55
+   Duration  224ms (transform 17ms, setup 0ms, collect 19ms, tests 4ms, environment 16ms, prepare 32ms)
+```
+
+> Providing `--project=edge` will run only those tests that match the `include` pattern of the `'edge'` workspace in `vitest.config.ts`.
diff --git a/exercises/04.performance/01.problem.profiling-slow-tests/README.mdx b/exercises/04.performance/01.problem.profiling-slow-tests/README.mdx
@@ -6,9 +6,9 @@ When it comes to dissecting any performance degradation, a gut feeling or a gues
 
 ## Profiling
 
-_Profiling_ is an essential process in analyzing code performance. Your tests are still code—the code you're testing wrapped in your test framework. Profiling it will come down to measuring critical points of the test's execution and analyzing the resulting report to see which areas consume most time/CPU/RAM/etc.
+_Profiling_ is an essential process in analyzing code performance. Your tests are still code—the code you're testing wrapped in your testing framework. Profiling it will come down to measuring critical points of the test's execution and analyzing the resulting report to see which areas consume most time/CPU/RAM/etc.
 
-You employ all sorts of tools to help you with profiling. From the built-in "Profiler" in your browser's DevTools to CPU and heap maps and even native profiling instruments in your test framework.
+You employ all sorts of tools to help you with profiling. From the built-in "Profiler" in your browser's DevTools to CPU and heap maps and even native profiling instruments in your testing framework.
 
 But it all starts from a slow test (or a few). In our case, we have a `rows.test.ts` test suite that's unusually slow:
 
diff --git a/exercises/04.performance/01.solution.profiling-slow-tests/README.mdx b/exercises/04.performance/01.solution.profiling-slow-tests/README.mdx
diff --git a/exercises/README.mdx b/exercises/README.mdx
diff --git a/package-lock.json b/package-lock.json
diff --git a/tsconfig.json b/tsconfig.json

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+export function slugify(input: string): string {`
	`2`	`+ return input.replace(/\s+/g, '-')`
	`3`	`+}`