01/01: add exercise texts

kettanaito · kettanaito · commit 5f23d245811f · 2025-04-21T17:13:54.000+02:00
diff --git a/exercises/01.setup/01.problem.vscode-extension/README.mdx b/exercises/01.setup/01.problem.vscode-extension/README.mdx
@@ -15,24 +15,12 @@ All of those things (and more) are provided by the official Vitest extension! Le
 
 > At the time of writing this, Vitest provides an official extension only for Visual Studio Code. Keep an eye on the [IDE integrations](https://vitest.dev/guide/#ide-integrations) for any future support for other IDEs.
 
-## Installing extension
+## Your task
 
-🐨 Install the [Vitest extension](https://marketplace.visualstudio.com/items?itemName=vitest.explorer) from Visual Studio Code Marketplace.
+👨‍💼 In this exercise, let's go through the steps needed to get the Vitest extension up and running together.
 
-And ... that's it! 🎉 Next, we will explore how to use the extension to iterate on tests faster and help you debug failed tests more efficiently.
+🐨 First, install the [Vitest extension](https://marketplace.visualstudio.com/items?itemName=vitest.explorer) from Visual Studio Code Marketplace (or search for "vitest" in the "Extensions" tab of the editor).
 
-## Running tests inline
+![](/assets/01-01-vitest-vscode-extension.png)
 
-Now, you can go to any test case in your project and click on the green "run" icon next to the test's name to run it inline. Vitest will report the test results right next to the test.
-
-> 🦉 You can run all tests or a subset of tests from the "Testing" tab in your explorer as well.
-
-## Continuous run
-
-Start a continuous run of your tests by going to the "Testing" tab and clicking on the "Start Continuous Run" button (with the eye icon) in the controls panel of the extension. You will be prompted to choose test files to run in continuous (i.e. watch) mode.
-
-Once the continuous run is active, you will see the test results _immediately_ as you work on your code or write your tests. This makes for a lightning-fast feedback loop when testing.
-
-## Debugging failed tests
-
-You can start a pre-configured debugging session for any test by clicking on the "Debug Test" button next to the failing test (or, alternatively, debug all tests via the "Debug Tests" button on the top panel). Use debuggers, breakpoints, and Debug Console to hunt down those nasty bugs and fix them.
+And ... that's it! 🎉 Next, let's explore how to use the extension to iterate on tests faster and help you debug failed tests more efficiently.
diff --git a/exercises/01.setup/01.solution.vscode-extension/.vscode/extensions.json b/exercises/01.setup/01.solution.vscode-extension/.vscode/extensions.json
@@ -0,0 +1,3 @@
+{
+	"recommendations": ["vitest.explorer"]
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/README.mdx b/exercises/01.setup/01.solution.vscode-extension/README.mdx
@@ -0,0 +1,27 @@
+# Visual Studio Code extension
+
+There is a couple of things that the Vitest extension enables you to do.
+
+## Running tests inline
+
+Now, you can go to any test case in your project and click on the green "run" icon next to the test's name to run it inline. Vitest will report the test results right next to the test.
+
+![A screenshot of Visual Studio Code with a test file open. On the left, next to the test name, a green play button displays a hint "Click to run tests, right click for more options".](/assets/01-01-run-tests-inline.png)
+
+Alternatively, head to the "Testing" tab of your editor and use the extension controls to run, watch, and debug any test suites or test cases you need:
+
+![A screenshot of Visual Studio Code with the "Testing" tab open to the right. A list of tests is displayed, and the cursor is hovering over the play button next to a test case that says "Run Test".](/assets/01-01-run-tests-extension.png)
+
+## Continuous run
+
+Start a continuous run of your tests by going to the "Testing" tab and clicking on the "Start Continuous Run" button (with the eye icon) in the controls panel of the extension. You will be prompted to choose test files to run in continuous (i.e. watch) mode.
+
+![A screenshot of Visual Studio Code with the failed assertion displayed inline next to the assertion itself. Below, an open terminal displays an extended diff between the expected and the actual results.](/assets/01-01-watch-mode.png)
+
+Once the continuous run is active, you will see the test results _immediately_ as you work on your code or write your tests, both in the terminal and next to the failing assertions. This makes for a lightning-fast feedback loop when testing.
+
+## Debugging failed tests
+
+You can start a pre-configured debugging session for any test by clicking on the "Debug Test" button next to the failing test (or, alternatively, debug all tests via the "Debug Tests" button on the top panel). Use debuggers, breakpoints, and Debug Console to hunt down those nasty bugs and fix them.
+
+![A screenshot of Visual Studio Code with a breakpoint set next to a line in the test. The "Testing" panel is open on the right, and the cursor is over the button that says "Debug Test".](/assets/01-01-debug-test.png)
diff --git a/exercises/01.setup/01.solution.vscode-extension/package.json b/exercises/01.setup/01.solution.vscode-extension/package.json
@@ -0,0 +1,13 @@
+{
+  "type": "module",
+  "name": "exercises_01.setup_01.solution.vscode-extension",
+  "scripts": {
+    "dev": "vite",
+    "test": "vitest",
+    "build": "vite build"
+  },
+  "devDependencies": {
+    "vite": "^6.2.6",
+    "vitest": "^3.1.1"
+  }
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/src/sort-by.test.ts b/exercises/01.setup/01.solution.vscode-extension/src/sort-by.test.ts
@@ -0,0 +1,27 @@
+import { sortBy } from './sort-by'
+
+test('sorts a list of fruits by their name', () => {
+	expect(
+		sortBy(
+			[{ name: 'Banana' }, { name: 'Apple' }, { name: 'Cucumber' }],
+			'name',
+		),
+	).toEqual([{ name: 'Apple' }, { name: 'Banana' }, { name: 'Cucumber' }])
+})
+
+test('sorts a list of players by their score', () => {
+	expect(
+		sortBy(
+			[
+				{ name: 'John', score: 10 },
+				{ name: 'Allen', score: 5 },
+				{ name: 'Sarah', score: 21 },
+			],
+			'score',
+		),
+	).toEqual([
+		{ name: 'Sarah', score: 21 },
+		{ name: 'John', score: 10 },
+		{ name: 'Allen', score: 5 },
+	])
+})
diff --git a/exercises/01.setup/01.solution.vscode-extension/src/sort-by.ts b/exercises/01.setup/01.solution.vscode-extension/src/sort-by.ts
@@ -0,0 +1,12 @@
+export function sortBy<T extends Record<string, unknown>>(
+	list: Array<T>,
+	sortKey: keyof T,
+): Array<T> {
+	const clone = structuredClone(list)
+
+	clone.sort((left, right) => {
+		return left[sortKey] < right[sortKey] ? -1 : 1
+	})
+
+	return clone
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/tsconfig.app.json b/exercises/01.setup/01.solution.vscode-extension/tsconfig.app.json
@@ -0,0 +1,5 @@
+{
+	"extends": "./tsconfig.base.json",
+	"include": ["src/**/*"],
+	"exclude": ["src/**/*.test.ts*"]
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/tsconfig.base.json b/exercises/01.setup/01.solution.vscode-extension/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/01.solution.vscode-extension/tsconfig.json b/exercises/01.setup/01.solution.vscode-extension/tsconfig.json
@@ -0,0 +1,8 @@
+{
+	"files": [],
+	"references": [
+		{ "path": "./tsconfig.app.json" },
+		{ "path": "./tsconfig.node.json" },
+		{ "path": "./tsconfig.test.json" }
+	]
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/tsconfig.node.json b/exercises/01.setup/01.solution.vscode-extension/tsconfig.node.json
@@ -0,0 +1,7 @@
+{
+	"extends": "./tsconfig.base.json",
+	"compilerOptions": {
+		"lib": ["ES2023"]
+	},
+	"include": ["vitest.config.ts"]
+}
diff --git a/exercises/01.setup/01.solution.vscode-extension/tsconfig.test.json b/exercises/01.setup/01.solution.vscode-extension/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/01.solution.vscode-extension/vitest.config.ts b/exercises/01.setup/01.solution.vscode-extension/vitest.config.ts
@@ -0,0 +1,10 @@
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+	server: {
+		port: process.env.PORT ? Number(process.env.PORT) : undefined,
+	},
+	test: {
+		globals: true,
+	},
+})
diff --git a/exercises/04.performance/03.problem.test-isolation/README.mdx b/exercises/04.performance/03.problem.test-isolation/README.mdx
@@ -0,0 +1,31 @@
+# Test isolation
+
+By default, Vitest runs each test file in an isolated environment (a worker, a forked process, or a VM context). That is a sensible default to make sure that no state gets leaked between test files and also make it a bit easier for you to orchestrate test setup as you don't have to worry about the entire test suite at once, just a single test file at a time.
+
+That being said, test isolation comes with a cost as spawning workers and processes takes time. Depending on the size of your test suite, that time can range from unsubstantial to quite drastic. That is why sometimes disabling test isolation can speed up your test run.
+
+<callout-warning>I am obligated to remind you that, much like concurrency, disabling test isolation is _never a solution to a problem_. It's a change in how your testing framework runs, and it often requires you to adjust your tests in order to benefit from it.</callout-warning>
+
+## When to disable test isolation?
+
+As with concurrency that we've covered previously, turning off test isolation is a conscious choice that comes with a price. It is worth mentioning that when I talk about disabling isolation, I only refer to _changing how Vitest runs your test files_. In other words, it's about telling Vitest _not_ to spend time dealing with workers/forks/vms when running tests.
+
+**When you disable test isolation, you're telling Vitest, "_It's alright, I've got the isolation covered myself_."** Isolation as a characteristic of your test suite is _mandatory_ for reliable and trustworthy testing. That is precisely why Vitest comes with isolation built-in—to help you write self-contained, independent tests. You don't need Vitest's test isolation to do that, it just makes it simpler.
+
+Isolation is the overarching theme when it comes to test performance. Reliable test runs cannot be achieved without properly isolated tests. This puts a similar list of criteria for disabling test isolation as we had for enabling concurrency:
+
+- Self-contained, independent tests;
+- Limited or properly managed side effects;
+- Carefully arranged test setup.
+
+This also means that you can benefit from correctly written tests in more ways than one. You can make them concurrent _and_ stop paying extra time for built-in isolation in Vitest since you've got it covered already.
+
+> I firmly believe that while right decisions are hard, one right decision leads to two right decisions, and so on.
+
+### Reading metrics
+
+Since disabling test isolation is an effort, you have to know if it's the said isolation that contributes to your tests being slow.
+
+TODO:
+
+- How do I know that it's test isolation that takes significant time? Is it displayed in some metric in Vitest?
diff --git a/exercises/04.performance/03.problem.test-isolation/package.json b/exercises/04.performance/03.problem.test-isolation/package.json
@@ -0,0 +1,13 @@
+{
+  "type": "module",
+  "name": "exercises_04.performance_03.problem.test-isolation",
+  "scripts": {
+    "dev": "vite",
+    "test": "vitest",
+    "build": "vite build"
+  },
+  "devDependencies": {
+    "vite": "^6.2.6",
+    "vitest": "^3.1.1"
+  }
+}
diff --git a/exercises/04.performance/03.problem.test-isolation/tsconfig.app.json b/exercises/04.performance/03.problem.test-isolation/tsconfig.app.json
@@ -0,0 +1,9 @@
+{
+	"extends": "./tsconfig.base.json",
+	"include": ["src/**/*"],
+	"exclude": ["src/**/*.test.ts*"],
+	"compilerOptions": {
+		"lib": ["ES2020", "DOM", "DOM.Iterable"],
+		"jsx": "react-jsx"
+	}
+}
diff --git a/exercises/04.performance/03.problem.test-isolation/tsconfig.base.json b/exercises/04.performance/03.problem.test-isolation/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/04.performance/03.problem.test-isolation/tsconfig.json b/exercises/04.performance/03.problem.test-isolation/tsconfig.json
@@ -0,0 +1,8 @@
+{
+	"files": [],
+	"references": [
+		{ "path": "./tsconfig.app.json" },
+		{ "path": "./tsconfig.node.json" },
+		{ "path": "./tsconfig.test.json" }
+	]
+}
diff --git a/exercises/04.performance/03.problem.test-isolation/tsconfig.node.json b/exercises/04.performance/03.problem.test-isolation/tsconfig.node.json
@@ -0,0 +1,7 @@
+{
+	"extends": "./tsconfig.base.json",
+	"compilerOptions": {
+		"lib": ["ES2023"]
+	},
+	"include": ["vitest.config.ts"]
+}
diff --git a/exercises/04.performance/03.problem.test-isolation/tsconfig.test.json b/exercises/04.performance/03.problem.test-isolation/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/04.performance/03.problem.test-isolation/vitest.config.ts b/exercises/04.performance/03.problem.test-isolation/vitest.config.ts
@@ -0,0 +1,10 @@
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+	server: {
+		port: process.env.PORT ? Number(process.env.PORT) : undefined,
+	},
+	test: {
+		globals: true,
+	},
+})
diff --git a/exercises/04.performance/03.solution.test-isolation/README.mdx b/exercises/04.performance/03.solution.test-isolation/README.mdx
@@ -1,35 +1,5 @@
 # Test isolation
 
-By default, Vitest runs each test file in an isolated environment (a worker, a forked process, or a VM context). That is a sensible default to make sure that no state gets leaked between test files and also make it a bit easier for you to orchestrate test setup as you don't have to worry about the entire test suite at once, just a single test file at a time.
-
-That being said, test isolation comes with a cost as spawning workers and processes takes time. Depending on the size of your test suite, that time can range from unsubstantial to quite drastic. That is why sometimes disabling test isolation can speed up your test run.
-
-<callout-warning>I am obligated to remind you that, much like concurrency, disabling test isolation is _never a solution to a problem_. It's a change in how your testing framework runs, and it often requires you to adjust your tests in order to benefit from it.</callout-warning>
-
-## When to disable test isolation?
-
-As with concurrency that we've covered previously, turning off test isolation is a conscious choice that comes with a price. It is worth mentioning that when I talk about disabling isolation, I only refer to _changing how Vitest runs your test files_. In other words, it's about telling Vitest _not_ to spend time dealing with workers/forks/vms when running tests.
-
-**When you disable test isolation, you're telling Vitest, "_It's alright, I've got the isolation covered myself_."** Isolation as a characteristic of your test suite is _mandatory_ for reliable and trustworthy testing. That is precisely why Vitest comes with isolation built-in—to help you write self-contained, independent tests. You don't need Vitest's test isolation to do that, it just makes it simpler.
-
-Isolation is the overarching theme when it comes to test performance. Reliable test runs cannot be achieved without properly isolated tests. This puts a similar list of criteria for disabling test isolation as we had for enabling concurrency:
-
-- Self-contained, independent tests;
-- Limited or properly managed side effects;
-- Carefully arranged test setup.
-
-This also means that you can benefit from correctly written tests in more ways than one. You can make them concurrent _and_ stop paying extra time for built-in isolation in Vitest since you've got it covered already.
-
-> I firmly believe that while right decisions are hard, one right decision leads to two right decisions, and so on.
-
-### Reading metrics
-
-Since disabling test isolation is an effort, you have to know if it's the said isolation that contributes to your tests being slow.
-
-TODO:
-
-- How do I know that it's test isolation that takes significant time? Is it displayed in some metric in Vitest?
-
 ## Disabling test isolation
 
 You can disable test isolation in Vitest by setting the `test.isolate` option to `false` in your Vitest configuration:
diff --git a/public/assets/01-01-debug-test.png b/public/assets/01-01-debug-test.png
diff --git a/public/assets/01-01-run-tests-extension.png b/public/assets/01-01-run-tests-extension.png
diff --git a/public/assets/01-01-run-tests-inline.png b/public/assets/01-01-run-tests-inline.png
diff --git a/public/assets/01-01-vitest-vscode-extension.png b/public/assets/01-01-vitest-vscode-extension.png
diff --git a/public/assets/01-01-watch-mode.png b/public/assets/01-01-watch-mode.png
diff --git a/tsconfig.json b/tsconfig.json
@@ -7,6 +7,9 @@
     {
       "path": "exercises/01.setup/01.problem.vscode-extension"
     },
+    {
+      "path": "exercises/01.setup/01.solution.vscode-extension"
+    },
     {
       "path": "exercises/01.setup/02.solution.multiple-workspaces"
     },
@@ -58,6 +61,9 @@
     {
       "path": "exercises/04.performance/02.solution.concurrency"
     },
+    {
+      "path": "exercises/04.performance/03.problem.test-isolation"
+    },
     {
       "path": "exercises/04.performance/03.solution.test-isolation"
     },

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+{`
	`2`	`+ "recommendations": ["vitest.explorer"]`
	`3`	`+}`