nuxt-spec 0.2.0-alpha.8 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,364 +1,364 @@
1
- # Nuxt Spec
2
-
3
- ![Nuxt Spec](https://github.com/AloisSeckar/nuxt-spec/blob/main/public/nuxt-spec.png)
4
-
5
- **Nuxt Spec** (aka `nuxt-spec`) is a base layer for [Nuxt](https://nuxt.com/) applications incorporating together a couple of testing libraries and packages and providing some utility functions. I created this project in early 2025 because I was unable to find a convenient "one-dependency" way to start testing my Nuxt apps and I didn't want to repeat the same steps and maintain the same set of dependencies over and over.
6
-
7
- While Nuxt itself does have a [dedicated module for testing](https://nuxt.com/docs/getting-started/testing), to remain as versatile as possible, it has to be combined with other packages (which can be different based on your choice). I am trying to overcome this by defining "The Way". This is both the strength and the weakness of this project. You were warned.
8
-
9
- The most important client of `nuxt-spec` is my [Nuxt Ignis](https://github.com/AloisSeckar/nuxt-ignis) template starter that adds up even more ready-to-use cool stuff for your future awesome Nuxt websites.
10
-
11
- ## How to use
12
-
13
- Aside from being "forked" and used as you see fit, `nuxt-spec` is also available as an [NPM package](https://www.npmjs.com/package/nuxt-spec) that can be referenced as a single-import with all the features incoming.
14
-
15
- The `nuxt-spec` package comes with a built-in CLI tool that can help you:
16
- - setup the dependency in your project
17
- - scaffold the default `vitest.config.ts` (see [configuration](#configuration) section)
18
- - add a few test-related script shorthands into your `package.json` (see [running tests](#running-tests) section)
19
- - create demo test files in proposed file structure
20
-
21
- To use it, just run the CLI script in your terminal:
22
-
23
- | Manager | Command |
24
- |-----------------|---------|
25
- | npm | `npx nuxt-spec setup` |
26
- | yarn | `yarn dlx nuxt-spec setup` |
27
- | pnpm | `pnpx nuxt-spec setup` |
28
- | Bun | `bunx nuxt-spec setup` |
29
- | Deno | `deno run --allow-run npm:npx nuxt-spec setup` |
30
-
31
- First, the CLI tool will ask you whether you want to do the setup automatically. If you choose `y`es, it will perform all the steps for you. If you choose `n`o, it will guide you through the manual setup step-by-step (see [manual setup](#manual-setup) section).
32
-
33
- ### Manual setup
34
-
35
- If you don't want to use the CLI tool, or you want to understand its flow better, here are the detailed steps:
36
-
37
- 1) Add following dependency into your `package.json`:
38
-
39
- ```
40
- "nuxt-spec": "0.2.0-alpha.8"
41
- ```
42
-
43
- 2) Add following section into your `nuxt.config.ts`:
44
-
45
- ```
46
- extends: [
47
- 'nuxt-spec'
48
- ]
49
- ```
50
-
51
- 3) Add `pnpm-workspace.yaml` file with following content (if you don't have it yet):
52
-
53
- ```
54
- shamefullyHoist: true
55
- ```
56
-
57
- 4) Add `vitest.config.ts` file with following content (if you don't have it yet):
58
-
59
- ```ts
60
- import { loadVitestConfig } from 'nuxt-spec/config'
61
-
62
- export default loadVitestConfig({
63
- // your custom config here
64
- })
65
- ```
66
-
67
- 5) (Optional) Add following scripts into your `package.json`:
68
-
69
- ```
70
- "scripts": {
71
- "test": "vitest run",
72
- "test-u": "vitest run -u",
73
- "test-i": "vitest"
74
- }
75
- ```
76
-
77
- 6) (Optional) Setup file structures for tests as follows:
78
-
79
- ```
80
- test/
81
- ├── browser/
82
- │ └── vitest-browser.test.ts
83
- ├── e2e/
84
- │ └── nuxt-e2e.test.ts
85
- │ └── nuxt-visual.test.ts
86
- ├── nuxt/
87
- │ └── nuxt-unit.test.ts
88
- └── unit/
89
- └── vitest-unit.test.ts
90
- ```
91
-
92
- You can use sample files from the [project repository](https://github.com/AloisSeckar/nuxt-spec/tree/v0.2.0-alpha.8/test).
93
-
94
- ### Install and execute
95
-
96
- Whether you used the CLI tool or did the manual setup, you are ready to install and run the tests.
97
-
98
- 1) Install the dependencies:
99
-
100
- <!-- tabs:start -->
101
-
102
- #### **npm**
103
-
104
- ```bash
105
- npm install
106
- ```
107
-
108
- #### **yarn**
109
-
110
- ```bash
111
- yarn install
112
- ```
113
-
114
- #### **pnpm**
115
-
116
- ```bash
117
- pnpm install
118
- ```
119
-
120
- #### **bun**
121
-
122
- ```bash
123
- bun install
124
- ```
125
-
126
- <!-- tabs:end -->
127
-
128
- 2) If you're prompted (for the first time when installing to a new machine), install headless browser runtimes:
129
-
130
- <!-- tabs:start -->
131
-
132
- #### **npm**
133
-
134
- ```bash
135
- npx playwright-core install
136
- ```
137
-
138
- #### **yarn**
139
-
140
- ```bash
141
- yarn dlx playwright-core install
142
- ```
143
-
144
- #### **pnpm**
145
-
146
- ```bash
147
- pnpm exec playwright-core install
148
- ```
149
-
150
- #### **bun**
151
-
152
- ```bash
153
- bunx playwright-core install
154
- ```
155
-
156
- <!-- tabs:end -->
157
-
158
- 3) Start the development server of your awesome Nuxt project:
159
-
160
- <!-- tabs:start -->
161
-
162
- #### **npm**
163
-
164
- ```bash
165
- npm run dev
166
- ```
167
-
168
- #### **yarn**
169
-
170
- ```bash
171
- yarn dev
172
- ```
173
-
174
- #### **pnpm**
175
-
176
- ```bash
177
- pnpm dev
178
- ```
179
-
180
- #### **bun**
181
-
182
- ```bash
183
- bun run dev
184
- ```
185
-
186
- <!-- tabs:end -->
187
-
188
- ### Running tests
189
-
190
- Once installed, Vitest automatically discovers all `*.test.ts` and `*.spec.ts` files in project and becomes capable of running them.
191
-
192
- You can use those three optional commands `package.json` file in `"scripts"` section in order to run tests easily:
193
- - `test: vitest run` - runs once and ends
194
- - `test-u: vitest run -u` - runs once and updates snapshots
195
- - `test-i: vitest` - runs and waits in HMR mode for test file changes
196
-
197
- Then you can call in terminal in root of your project:
198
-
199
- <!-- tabs:start -->
200
-
201
- #### **npm**
202
-
203
- ```bash
204
- npm run test # runs once and ends
205
- npm run test-u # runs once and updates snapshots
206
- npm run test-i # runs and waits in HMR mode
207
- ```
208
-
209
- #### **yarn**
210
-
211
- ```bash
212
- yarn test # runs once and ends
213
- yarn test-u # runs once and updates snapshots
214
- yarn test-i # runs and waits in HMR mode
215
- ```
216
-
217
- #### **pnpm**
218
-
219
- ```bash
220
- pnpm test # runs once and ends
221
- pnpm test-u # runs once and updates snapshots
222
- pnpm test-i # runs and waits in HMR mode
223
- ```
224
-
225
- #### **bun**
226
-
227
- ```bash
228
- bun run test # runs once and ends
229
- bun run test-u # runs once and updates snapshots
230
- bun run test-i # runs and waits in HMR mode
231
- ```
232
-
233
- <!-- tabs:end -->
234
-
235
- Or you can use the `vitest` command directly with all its parameters. See [Vitest CLI documentation](https://vitest.dev/guide/cli.html) for more info.
236
-
237
- ## Overview
238
-
239
- **Nuxt Spec** currently contains:
240
- - [vitest](https://www.npmjs.com/package/vitest) **v4** as the fundamental testing framework
241
- - [@vitest/browser](https://www.npmjs.com/package/@vitest/browser) as more advanced browser-native testing runner
242
- - [@vitest/ui](https://www.npmjs.com/package/@vitest/ui) as graphic UI above the Vitest test runner
243
- - [happy-dom](https://www.npmjs.com/package/happy-dom) as the headless browser runtime
244
- - [playwright-core](https://www.npmjs.com/package/playwright-core) as the headless browser testing framework
245
- - [@vue/test-utils](https://www.npmjs.com/package/@vue/test-utils) for testing Vue stuff
246
- - [@nuxt/test-utils](https://www.npmjs.com/package/@nuxt/test-utils) for testing Nuxt stuff
247
-
248
- Planned future development:
249
- - reason about (not) using Vitest browser mode (or make it optional)
250
- - solution for visual regression testing - (currently there is experimental custom solution)
251
-
252
- See [CHANGELOG.md](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0-alpha.8/CHANGELOG.md) for the latest updates and features.
253
-
254
- ## Configuration
255
-
256
- By default, `nuxt-spec` uses Vitest configuration defined in [`/config/index.mjs`](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0-alpha.8/config/index.mjs). The configuration is based on [Nuxt team recommendations](https://nuxt.com/docs/4.x/getting-started/testing) and our best judgement.
257
-
258
- To add/override your custom config, you can create (or scaffold via CLI tool) a file named `vitest.config.ts` in the root of your project with the following content:
259
-
260
- ```ts
261
- import { loadVitestConfig } from 'nuxt-spec/config'
262
-
263
- export default loadVitestConfig({
264
- // your custom config here
265
- })
266
- ```
267
-
268
- And pass whatever you want as a parameter object. It will be defu-merged with the defaults (custom config takes precedence). The object is typed to be compatible with both [Vite](https://vite.dev/config/) and [Vitest](https://vitest.dev/config/) configuration options. Used type is derived from the respective `.d.ts` files of those packages.
269
-
270
- **NOTE**: Based on the [Vitest documentation](https://main.vitest.dev/config/), it is possible to pass in **any configuration option** valid for [Vite](https://vite.dev/config/). Configuration related directly to Vitest must be passed under the `test` key, e.g.:
271
-
272
- ```ts
273
- import { loadVitestConfig } from 'nuxt-spec/config'
274
-
275
- export default loadVitestConfig({
276
- test: {
277
- // your custom config specific to Vitest here
278
- }
279
- // by the nature of the Vitest config resolution,
280
- // you may also pass ANY OTHER valid Vite configuration options here
281
- })
282
- ```
283
-
284
- By default, Nuxt Spec built-in configuration establishes 4 `projects` + one fallback:
285
- - `unit` - for unit tests in `test/unit/**` - env is set to `node`
286
- - `nuxt` - for Nuxt-related tests in `test/nuxt/**` - env is set to `nuxt`
287
- - `e2e` - for end-to-end tests in `test/e2e/**` - env is set to `node`
288
- - `browser` - for browser-mode tests in `test/browser/**` - env is set to `node` (this is effectively an alternative to `nuxt` relying on `@vitest/browser` instead of `@nuxt/test-utils`)
289
- - `default` - fallback for all other tests in `test/**` and/or `tests/**` directories - env is set to `node`
290
-
291
- Vitest will then expect at least one test defined in either of those directories. Any parts of the `test.projects` config may be altered and user-defined values will be logically merged with the defaults. Also you may add new custom projects' definitions to fit your needs. If your project uses significantly different configuration (i.e. your tests reside in completely different path), you can pass `false` as a second parameter to `loadVitestConfig()` function to exclude default `test.projects` values from being injected completely:
292
-
293
- ```ts
294
- import { loadVitestConfig } from 'nuxt-spec/config'
295
-
296
- export default loadVitestConfig({
297
- // your custom config here
298
- }, false)
299
- ```
300
-
301
- Alternatively, if you don't want to use any part of the `nuxt-spec` default configuration at all, you can override `vitest.config.ts` file completely and define your own [Vitest configuration](https://vitest.dev/config/) from scratch.
302
-
303
- ## Utilities
304
-
305
- Nuxt Spec offers a couple of utility functions that are exported via `nuxt-spec/utils` subpackage.
306
-
307
- You can use them in your test files as follows:
308
-
309
- ```ts
310
- import { compareScreenshot, gotoPage, getDataHtml, getAPIResultHtml, } from 'nuxt-spec/utils'
311
-
312
- // accepts instance of NuxtPage (from @nuxt/test-utils)
313
- // takes a screenshot of current viewport and compares it with stored baseline
314
- // the comparison is done using `pixelmatch` library
315
- // if screenshot doesn't exist, it will be created in __baseline__ subfolder
316
- // screenshot from current run is always captured into __current__ subfolder
317
- // if screenshots don't match, the method will cause Vitest test to fail
318
- // accepts optional object with extra options:
319
- // - `fileName` - name of the screenshot file (default is based on current route)
320
- // - `selector` - CSS selector of the element to capture (default is full page)
321
- // - `targetDir` - directory where the screenshots should be stored (default is `./test/e2e/`)
322
- // - `maxDiffPixelRatio` - allows mitigating cross-platform rendering differences by setting
323
- // a 0-1 scale tolerance (default 0)
324
- // - `maxDiffPixels` - same but with exact max value of different pixels which overrides setting
325
- // `maxDiffPixelRatio` (default 0)
326
- // - `threshold` - allows adjusting the tolerance for "same" color on 0-1 scale (default 0.1)
327
-
328
- // will produce "index.png" file in `./test/e2e/` directory
329
- await compareScreenshot(page)
330
- // will produce "homepage.png"
331
- await compareScreenshot(page, { fileName: 'homepage.png' })
332
- // will produce "component.png" only with id="test" element
333
- await compareScreenshot(page, { fileName: 'component.png', selector: '#test' })
334
- // will produce "homepage.png" in `/screenshots` directory
335
- await compareScreenshot(page, { fileName: 'homepage.png', targetDir: '/screenshots' })
336
- // will produce "homepage.png" and the comparison will only fail when more than 1000 pixels differ
337
- await compareScreenshot(page, { fileName: 'homepage.png', maxDiffPixels: 1000 })
338
- // will produce "homepage.png", the comparison will only fail when more than 1000 pixels differ
339
- // while more pixels will be considered "same" based on color
340
- await compareScreenshot(page, { fileName: 'homepage.png', maxDiffPixels: 1000, threshold: 0.5 })
341
-
342
- // navigates to given URL and returns the instance of NuxtPage (from @nuxt/test-utils)
343
- const page: NuxtPage = await gotoPage('url')
344
-
345
- // accepts either a URL string or instance of NuxtPage (from @nuxt/test-utils) and a CSS selector
346
- // returns `innerHTML` of the element matching the selector
347
- const html: string = await getDataHtml('/', '#test')
348
- const html: string = await getDataHtml(page, '#test')
349
-
350
- // accepts either a URL string or instance of NuxtPage (from @nuxt/test-utils)
351
- // css selector for element that triggers API call when clicked (i.e. button)
352
- // fragment of API endpoint URL that should be called (to test the response)
353
- // css selector for element where the API response should be rendered (i.e. div)
354
- // returns `innerHTML` of the element matching the result selector after the API call
355
- // is made by Playwright runner
356
- const html: string = await getAPIResultHtml('/', '#api-fetch', '/your-api', '#api-result')
357
- const html: string = await getAPIResultHtml(page, '#api-fetch', '/your-api', '#api-result')
358
- ```
359
-
360
- For detailed description, see [utils.d.ts](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0-alpha.8/utils/index.d.ts).
361
-
362
- ## Contact
363
-
364
- Use GitHub issues to report bugs or suggest improvements. I will be more than happy to address them.
1
+ # Nuxt Spec
2
+
3
+ ![Nuxt Spec](https://github.com/AloisSeckar/nuxt-spec/blob/main/public/nuxt-spec.png)
4
+
5
+ **Nuxt Spec** (aka `nuxt-spec`) is a base layer for [Nuxt](https://nuxt.com/) applications incorporating together a couple of testing libraries and packages and providing some utility functions. I created this project in early 2025 because I was unable to find a convenient "one-dependency" way to start testing my Nuxt apps and I didn't want to repeat the same steps and maintain the same set of dependencies over and over.
6
+
7
+ While Nuxt itself does have a [dedicated module for testing](https://nuxt.com/docs/getting-started/testing), to remain as versatile as possible, it has to be combined with other packages (which can be different based on your choice). I am trying to overcome this by defining "The Way". This is both the strength and the weakness of this project. You were warned.
8
+
9
+ The most important client of `nuxt-spec` is my [Nuxt Ignis](https://github.com/AloisSeckar/nuxt-ignis) template starter that adds up even more ready-to-use cool stuff for your future awesome Nuxt websites.
10
+
11
+ ## How to use
12
+
13
+ Aside from being "forked" and used as you see fit, `nuxt-spec` is also available as an [NPM package](https://www.npmjs.com/package/nuxt-spec) that can be referenced as a single-import with all the features incoming.
14
+
15
+ The `nuxt-spec` package comes with a built-in CLI tool that can help you:
16
+ - setup the dependency in your project
17
+ - scaffold the default `vitest.config.ts` (see [configuration](#configuration) section)
18
+ - add a few test-related script shorthands into your `package.json` (see [running tests](#running-tests) section)
19
+ - create demo test files in proposed file structure
20
+
21
+ To use it, just run the CLI script in your terminal:
22
+
23
+ | Manager | Command |
24
+ |-----------------|---------|
25
+ | npm | `npx nuxt-spec setup` |
26
+ | yarn | `yarn dlx nuxt-spec setup` |
27
+ | pnpm | `pnpx nuxt-spec setup` |
28
+ | Bun | `bunx nuxt-spec setup` |
29
+ | Deno | `deno run --allow-run npm:npx nuxt-spec setup` |
30
+
31
+ First, the CLI tool will ask you whether you want to do the setup automatically. If you choose `y`es, it will perform all the steps for you. If you choose `n`o, it will guide you through the manual setup step-by-step (see [manual setup](#manual-setup) section).
32
+
33
+ ### Manual setup
34
+
35
+ If you don't want to use the CLI tool, or you want to understand its flow better, here are the detailed steps:
36
+
37
+ 1) Add following dependency into your `package.json`:
38
+
39
+ ```
40
+ "nuxt-spec": "0.2.0"
41
+ ```
42
+
43
+ 2) Add following section into your `nuxt.config.ts`:
44
+
45
+ ```
46
+ extends: [
47
+ 'nuxt-spec'
48
+ ]
49
+ ```
50
+
51
+ 3) Add `pnpm-workspace.yaml` file with following content (if you don't have it yet):
52
+
53
+ ```
54
+ shamefullyHoist: true
55
+ ```
56
+
57
+ 4) Add `vitest.config.ts` file with following content (if you don't have it yet):
58
+
59
+ ```ts
60
+ import { loadVitestConfig } from 'nuxt-spec/config'
61
+
62
+ export default loadVitestConfig({
63
+ // your custom config here
64
+ })
65
+ ```
66
+
67
+ 5) (Optional) Add following scripts into your `package.json`:
68
+
69
+ ```
70
+ "scripts": {
71
+ "test": "vitest run",
72
+ "test-u": "vitest run -u",
73
+ "test-i": "vitest"
74
+ }
75
+ ```
76
+
77
+ 6) (Optional) Setup file structures for tests as follows:
78
+
79
+ ```
80
+ test/
81
+ ├── browser/
82
+ │ └── vitest-browser.test.ts
83
+ ├── e2e/
84
+ │ └── nuxt-e2e.test.ts
85
+ │ └── nuxt-visual.test.ts
86
+ ├── nuxt/
87
+ │ └── nuxt-unit.test.ts
88
+ └── unit/
89
+ └── vitest-unit.test.ts
90
+ ```
91
+
92
+ You can use sample files from the [project repository](https://github.com/AloisSeckar/nuxt-spec/tree/v0.2.0/test).
93
+
94
+ ### Install and execute
95
+
96
+ Whether you used the CLI tool or did the manual setup, you are ready to install and run the tests.
97
+
98
+ 1) Install the dependencies:
99
+
100
+ <!-- tabs:start -->
101
+
102
+ #### **npm**
103
+
104
+ ```bash
105
+ npm install
106
+ ```
107
+
108
+ #### **yarn**
109
+
110
+ ```bash
111
+ yarn install
112
+ ```
113
+
114
+ #### **pnpm**
115
+
116
+ ```bash
117
+ pnpm install
118
+ ```
119
+
120
+ #### **bun**
121
+
122
+ ```bash
123
+ bun install
124
+ ```
125
+
126
+ <!-- tabs:end -->
127
+
128
+ 2) If you're prompted (for the first time when installing to a new machine), install headless browser runtimes:
129
+
130
+ <!-- tabs:start -->
131
+
132
+ #### **npm**
133
+
134
+ ```bash
135
+ npx playwright-core install
136
+ ```
137
+
138
+ #### **yarn**
139
+
140
+ ```bash
141
+ yarn dlx playwright-core install
142
+ ```
143
+
144
+ #### **pnpm**
145
+
146
+ ```bash
147
+ pnpm exec playwright-core install
148
+ ```
149
+
150
+ #### **bun**
151
+
152
+ ```bash
153
+ bunx playwright-core install
154
+ ```
155
+
156
+ <!-- tabs:end -->
157
+
158
+ 3) Start the development server of your awesome Nuxt project:
159
+
160
+ <!-- tabs:start -->
161
+
162
+ #### **npm**
163
+
164
+ ```bash
165
+ npm run dev
166
+ ```
167
+
168
+ #### **yarn**
169
+
170
+ ```bash
171
+ yarn dev
172
+ ```
173
+
174
+ #### **pnpm**
175
+
176
+ ```bash
177
+ pnpm dev
178
+ ```
179
+
180
+ #### **bun**
181
+
182
+ ```bash
183
+ bun run dev
184
+ ```
185
+
186
+ <!-- tabs:end -->
187
+
188
+ ### Running tests
189
+
190
+ Once installed, Vitest automatically discovers all `*.test.ts` and `*.spec.ts` files in project and becomes capable of running them.
191
+
192
+ You can use those three optional commands `package.json` file in `"scripts"` section in order to run tests easily:
193
+ - `test: vitest run` - runs once and ends
194
+ - `test-u: vitest run -u` - runs once and updates snapshots
195
+ - `test-i: vitest` - runs and waits in HMR mode for test file changes
196
+
197
+ Then you can call in terminal in root of your project:
198
+
199
+ <!-- tabs:start -->
200
+
201
+ #### **npm**
202
+
203
+ ```bash
204
+ npm run test # runs once and ends
205
+ npm run test-u # runs once and updates snapshots
206
+ npm run test-i # runs and waits in HMR mode
207
+ ```
208
+
209
+ #### **yarn**
210
+
211
+ ```bash
212
+ yarn test # runs once and ends
213
+ yarn test-u # runs once and updates snapshots
214
+ yarn test-i # runs and waits in HMR mode
215
+ ```
216
+
217
+ #### **pnpm**
218
+
219
+ ```bash
220
+ pnpm test # runs once and ends
221
+ pnpm test-u # runs once and updates snapshots
222
+ pnpm test-i # runs and waits in HMR mode
223
+ ```
224
+
225
+ #### **bun**
226
+
227
+ ```bash
228
+ bun run test # runs once and ends
229
+ bun run test-u # runs once and updates snapshots
230
+ bun run test-i # runs and waits in HMR mode
231
+ ```
232
+
233
+ <!-- tabs:end -->
234
+
235
+ Or you can use the `vitest` command directly with all its parameters. See [Vitest CLI documentation](https://vitest.dev/guide/cli.html) for more info.
236
+
237
+ ## Overview
238
+
239
+ **Nuxt Spec** currently contains:
240
+ - [vitest](https://www.npmjs.com/package/vitest) **v4** as the fundamental testing framework
241
+ - [@vitest/browser](https://www.npmjs.com/package/@vitest/browser) as more advanced browser-native testing runner
242
+ - [@vitest/ui](https://www.npmjs.com/package/@vitest/ui) as graphic UI above the Vitest test runner
243
+ - [happy-dom](https://www.npmjs.com/package/happy-dom) as the headless browser runtime
244
+ - [playwright-core](https://www.npmjs.com/package/playwright-core) as the headless browser testing framework
245
+ - [@vue/test-utils](https://www.npmjs.com/package/@vue/test-utils) for testing Vue stuff
246
+ - [@nuxt/test-utils](https://www.npmjs.com/package/@nuxt/test-utils) for testing Nuxt stuff
247
+
248
+ Planned future development:
249
+ - reason about (not) using Vitest browser mode (or make it optional)
250
+ - solution for visual regression testing - (currently there is experimental custom solution)
251
+
252
+ See [CHANGELOG.md](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0/CHANGELOG.md) for the latest updates and features.
253
+
254
+ ## Configuration
255
+
256
+ By default, `nuxt-spec` uses Vitest configuration defined in [`/config/index.mjs`](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0/config/index.mjs). The configuration is based on [Nuxt team recommendations](https://nuxt.com/docs/4.x/getting-started/testing) and our best judgement.
257
+
258
+ To add/override your custom config, you can create (or scaffold via CLI tool) a file named `vitest.config.ts` in the root of your project with the following content:
259
+
260
+ ```ts
261
+ import { loadVitestConfig } from 'nuxt-spec/config'
262
+
263
+ export default loadVitestConfig({
264
+ // your custom config here
265
+ })
266
+ ```
267
+
268
+ And pass whatever you want as a parameter object. It will be defu-merged with the defaults (custom config takes precedence). The object is typed to be compatible with both [Vite](https://vite.dev/config/) and [Vitest](https://vitest.dev/config/) configuration options. Used type is derived from the respective `.d.ts` files of those packages.
269
+
270
+ **NOTE**: Based on the [Vitest documentation](https://main.vitest.dev/config/), it is possible to pass in **any configuration option** valid for [Vite](https://vite.dev/config/). Configuration related directly to Vitest must be passed under the `test` key, e.g.:
271
+
272
+ ```ts
273
+ import { loadVitestConfig } from 'nuxt-spec/config'
274
+
275
+ export default loadVitestConfig({
276
+ test: {
277
+ // your custom config specific to Vitest here
278
+ }
279
+ // by the nature of the Vitest config resolution,
280
+ // you may also pass ANY OTHER valid Vite configuration options here
281
+ })
282
+ ```
283
+
284
+ By default, Nuxt Spec built-in configuration establishes 4 `projects` + one fallback:
285
+ - `unit` - for unit tests in `test/unit/**` - env is set to `node`
286
+ - `nuxt` - for Nuxt-related tests in `test/nuxt/**` - env is set to `nuxt`
287
+ - `e2e` - for end-to-end tests in `test/e2e/**` - env is set to `node`
288
+ - `browser` - for browser-mode tests in `test/browser/**` - env is set to `node` (this is effectively an alternative to `nuxt` relying on `@vitest/browser` instead of `@nuxt/test-utils`)
289
+ - `default` - fallback for all other tests in `test/**` and/or `tests/**` directories - env is set to `node`
290
+
291
+ Vitest will then expect at least one test defined in either of those directories. Any parts of the `test.projects` config may be altered and user-defined values will be logically merged with the defaults. Also you may add new custom projects' definitions to fit your needs. If your project uses significantly different configuration (i.e. your tests reside in completely different path), you can pass `false` as a second parameter to `loadVitestConfig()` function to exclude default `test.projects` values from being injected completely:
292
+
293
+ ```ts
294
+ import { loadVitestConfig } from 'nuxt-spec/config'
295
+
296
+ export default loadVitestConfig({
297
+ // your custom config here
298
+ }, false)
299
+ ```
300
+
301
+ Alternatively, if you don't want to use any part of the `nuxt-spec` default configuration at all, you can override `vitest.config.ts` file completely and define your own [Vitest configuration](https://vitest.dev/config/) from scratch.
302
+
303
+ ## Utilities
304
+
305
+ Nuxt Spec offers a couple of utility functions that are exported via `nuxt-spec/utils` subpackage.
306
+
307
+ You can use them in your test files as follows:
308
+
309
+ ```ts
310
+ import { compareScreenshot, gotoPage, getDataHtml, getAPIResultHtml, } from 'nuxt-spec/utils'
311
+
312
+ // accepts instance of NuxtPage (from @nuxt/test-utils)
313
+ // takes a screenshot of current viewport and compares it with stored baseline
314
+ // the comparison is done using `pixelmatch` library
315
+ // if screenshot doesn't exist, it will be created in __baseline__ subfolder
316
+ // screenshot from current run is always captured into __current__ subfolder
317
+ // if screenshots don't match, the method will cause Vitest test to fail
318
+ // accepts optional object with extra options:
319
+ // - `fileName` - name of the screenshot file (default is based on current route)
320
+ // - `selector` - CSS selector of the element to capture (default is full page)
321
+ // - `targetDir` - directory where the screenshots should be stored (default is `./test/e2e/`)
322
+ // - `maxDiffPixelRatio` - allows mitigating cross-platform rendering differences by setting
323
+ // a 0-1 scale tolerance (default 0)
324
+ // - `maxDiffPixels` - same but with exact max value of different pixels which overrides setting
325
+ // `maxDiffPixelRatio` (default 0)
326
+ // - `threshold` - allows adjusting the tolerance for "same" color on 0-1 scale (default 0.1)
327
+
328
+ // will produce "index.png" file in `./test/e2e/` directory
329
+ await compareScreenshot(page)
330
+ // will produce "homepage.png"
331
+ await compareScreenshot(page, { fileName: 'homepage.png' })
332
+ // will produce "component.png" only with id="test" element
333
+ await compareScreenshot(page, { fileName: 'component.png', selector: '#test' })
334
+ // will produce "homepage.png" in `/screenshots` directory
335
+ await compareScreenshot(page, { fileName: 'homepage.png', targetDir: '/screenshots' })
336
+ // will produce "homepage.png" and the comparison will only fail when more than 1000 pixels differ
337
+ await compareScreenshot(page, { fileName: 'homepage.png', maxDiffPixels: 1000 })
338
+ // will produce "homepage.png", the comparison will only fail when more than 1000 pixels differ
339
+ // while more pixels will be considered "same" based on color
340
+ await compareScreenshot(page, { fileName: 'homepage.png', maxDiffPixels: 1000, threshold: 0.5 })
341
+
342
+ // navigates to given URL and returns the instance of NuxtPage (from @nuxt/test-utils)
343
+ const page: NuxtPage = await gotoPage('url')
344
+
345
+ // accepts either a URL string or instance of NuxtPage (from @nuxt/test-utils) and a CSS selector
346
+ // returns `innerHTML` of the element matching the selector
347
+ const html: string = await getDataHtml('/', '#test')
348
+ const html: string = await getDataHtml(page, '#test')
349
+
350
+ // accepts either a URL string or instance of NuxtPage (from @nuxt/test-utils)
351
+ // css selector for element that triggers API call when clicked (i.e. button)
352
+ // fragment of API endpoint URL that should be called (to test the response)
353
+ // css selector for element where the API response should be rendered (i.e. div)
354
+ // returns `innerHTML` of the element matching the result selector after the API call
355
+ // is made by Playwright runner
356
+ const html: string = await getAPIResultHtml('/', '#api-fetch', '/your-api', '#api-result')
357
+ const html: string = await getAPIResultHtml(page, '#api-fetch', '/your-api', '#api-result')
358
+ ```
359
+
360
+ For detailed description, see [utils.d.ts](https://github.com/AloisSeckar/nuxt-spec/blob/v0.2.0/utils/index.d.ts).
361
+
362
+ ## Contact
363
+
364
+ Use GitHub issues to report bugs or suggest improvements. I will be more than happy to address them.