04/02: add problem text

Author: kettanaito

exercises/04.performance/01.problem.profiling-slow-tests/vitest.config.ts

@@ -1,6 +1,11 @@
 import { defineConfig } from 'vitest/config'
+// 🐨 Import `vitestProfiler` from `vitest-profiler/plugin`
 
 export default defineConfig({
+	// 🐨 Add a `plugins` property at the root of the Vitest configuration.
+	// Make it equal an array. Inside that array, call the `vitestProfiler`
+	// function you imported earlier.
+	// 💰 plugins: [somePlugin()],
 	test: {
 		globals: true,
 	},

exercises/04.performance/02.problem.concurrency/README.mdx

@@ -0,0 +1,46 @@
+# Concurrency
+
+For the remainder of this exercise block, I would like for us to focus on techniques to apply to performance issues caused by a _large number of tests_. Even if every single one of your test cases is blazingly-fast, if you have a million of them, your test run will still be slow.
+
+One of the ways to fix that is by utilizing _concurrency_.
+
+But before that, you need to understand how Vitest runs your tests.
+
+## Vitest test run
+
+By default, Vitest runs every _test file in parallel_ and every _test case (within the same test file) in sequence_. You can visualize your test run like this:
+
+<img
+	src="/assets/05-02-vitest-defaults.png"
+	alt="A schematics showing two test suites in a column, each containing a waterfall of test cases inside."
+	width="500"
+	style={{ margin: 'auto' }}
+/>
+
+Both `suite-a` and `suite-b` will run simultaneously in different workers, but test cases inside them will run one after another. In the end, your test run is only as fast as your slowest test suite.
+
+<callout-info>_Parallelism_ is enabled by default in Vitest but _not concurrency_.</callout-info>
+
+These defaults are intentional and are designed to prevent flakiness. Vitest can afford to run test suites in parallel because each test suite _runs in a separate worker_ (again, by default). Workers share the test environment but nothing else, which makes it safe to run them at the same time.
+
+On the other hand, all test cases within the same test suite run in the same worker. Here, the risk of shared state is higher, and so Vitest defaults to running them in sequence to prevent test cases from stepping on each other's toes.
+
+Both parallelism and concurrency can be configured in Vitest and in the right test suite can give you a significant boost in test performance. It's time you learned how.
+
+## Your task
+
+If you run `npm test`, you will notice how slow our test suite is:
+
+```
+ ✓ src/one.test.ts (100 tests) 2644ms
+ ✓ src/two.test.ts (100 tests) 2644ms
+
+ Test Files  2 passed (2)
+      Tests  200 passed (200)
+   Start at  12:24:45
+   Duration  2.91s (transform 25ms, setup 0ms, collect 25ms, tests 5.29s, environment 0ms, prepare 65ms)
+```
+
+It's not slow because tests are slow individually. It is slow because there are 200 tests in total, making the test run last a soul-crushing _3 seconds_.
+
+👨‍💼 Your task is to _improve that time_ by using concurrency. Head to those two test files and follow the instructions to make their test cases concurrent. Once you're done, run the tests again and see if you can spot a difference.

exercises/04.performance/02.problem.concurrency/package.json

@@ -0,0 +1,13 @@
+{
+  "type": "module",
+  "name": "exercises_04.performance_02.problem.concurrency",
+  "scripts": {
+    "dev": "vite",
+    "test": "vitest",
+    "build": "vite build"
+  },
+  "devDependencies": {
+    "vite": "^6.2.6",
+    "vitest": "^3.1.1"
+  }
+}

exercises/04.performance/02.problem.concurrency/src/one.test.ts

@@ -0,0 +1,10 @@
+import { setTimeout } from 'node:timers/promises'
+
+for (let i = 0; i < 100; i++) {
+	// 🐨 Replace the `test()` function below with `test.concurrent()`.
+	// This will make all the test cases in this test file run simultaneously.
+	test(`${i}`, async ({ expect }) => {
+		await setTimeout(25)
+		expect(i).toBe(i)
+	})
+}

exercises/04.performance/02.problem.concurrency/src/two.test.ts

@@ -0,0 +1,10 @@
+import { setTimeout } from 'node:timers/promises'
+
+for (let i = 0; i < 100; i++) {
+	// 🐨 Replace the `test()` function below with `test.concurrent()`.
+	// This will make all the test cases in this test file run simultaneously.
+	test(`${i}`, async ({ expect }) => {
+		await setTimeout(25)
+		expect(i).toBe(i)
+	})
+}

exercises/04.performance/02.problem.concurrency/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"
+	}
+}

exercises/04.performance/02.problem.concurrency/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
+	}
+}

exercises/04.performance/02.problem.concurrency/tsconfig.json

@@ -0,0 +1,8 @@
+{
+	"files": [],
+	"references": [
+		{ "path": "./tsconfig.app.json" },
+		{ "path": "./tsconfig.node.json" },
+		{ "path": "./tsconfig.test.json" }
+	]
+}

exercises/04.performance/02.problem.concurrency/tsconfig.node.json

@@ -0,0 +1,7 @@
+{
+	"extends": "./tsconfig.base.json",
+	"compilerOptions": {
+		"lib": ["ES2023"]
+	},
+	"include": ["vitest.config.ts"]
+}

exercises/04.performance/02.problem.concurrency/tsconfig.test.json

@@ -0,0 +1,8 @@
+{
+	"extends": "./tsconfig.app.json",
+	"include": ["src/**/*", "src/**/*.test.ts*"],
+	"exclude": [],
+	"compilerOptions": {
+		"types": ["vitest/globals"]
+	}
+}