You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/config/globalsetup.md
+32-22Lines changed: 32 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,26 +7,45 @@ outline: deep
7
7
8
8
-**Type:**`string | string[]`
9
9
10
-
Path to global setup files, relative to project root.
10
+
Path to global setup files relative to project [root](/config/root).
11
11
12
-
A global setup file can either export named functions `setup` and `teardown` or a `default` function that returns a teardown function ([example](https://github.com/vitest-dev/vitest/blob/main/test/global-setup/vitest.config.ts)).
12
+
A global setup file can either export named functions `setup` and `teardown` or a `default` function that returns a teardown function:
13
13
14
-
::: info
15
-
Multiple globalSetup files are possible. setup and teardown are executed sequentially with teardown in reverse order.
14
+
::: code-group
15
+
```js [exports]
16
+
exportfunctionsetup(project) {
17
+
console.log('setup')
18
+
}
19
+
20
+
exportfunctionteardown() {
21
+
console.log('teardown')
22
+
}
23
+
```
24
+
```js [default]
25
+
exportdefaultfunctionsetup(project) {
26
+
console.log('setup')
27
+
28
+
returnfunctionteardown() {
29
+
console.log('teardown')
30
+
}
31
+
}
32
+
```
16
33
:::
17
34
18
-
::: warning
19
-
Global setup runs only if there is at least one running test. This means that global setup might start running during watch mode after test file is changed (the test file will wait for global setup to finish before running).
35
+
Note that the `setup` method and a `default` function receive a [test project](/api/advanced/test-project) as the first argument. The global setup is called before the test workers are created and only if there is at least one test queued, and teardown is called after all test files have finished running. In [watch mode](/config/watch), the teardown is called before the process is exited instead. If you need to reconfigure your setup before the test rerun, you can use [`onTestsRerun`](#handling-test-reruns) hook instead.
20
36
21
-
Beware that the global setup is running in a different global scope, so your tests don't have access to variables defined here. However, you can pass down serializable data to tests via [`provide`](#provide) method:
37
+
Multiple global setup files are possible. `setup` and `teardown` are executed sequentially with teardown in reverse order.
38
+
39
+
::: danger
40
+
Beware that the global setup is running in a different global scope before test workers are even created, so your tests don't have access to global variables defined here. However, you can pass down serializable data to tests via [`provide`](/config/provide) method and read them in your tests via `inject` imported from `vitest`:
exportdefaultfunction setup({ provide }:GlobalSetupContext) {
46
-
provide('wsPort', 3000)
47
-
}
48
-
49
-
declaremodule'vitest' {
50
-
exportinterfaceProvidedContext {
51
-
wsPort:number
52
-
}
53
-
}
54
-
```
62
+
If you need to execute code in the same process as tests, use [`setupFiles`](/config/setupfiles) instead, but note that it runs before every test file.
55
63
:::
56
64
57
-
Since Vitest 3, you can define a custom callback function to be called when Vitest reruns tests. If the function is asynchronous, the runner will wait for it to complete before executing tests. Note that you cannot destruct the `project` like `{ onTestsRerun }` because it relies on the context.
65
+
### Handling Test Reruns
66
+
67
+
You can define a custom callback function to be called when Vitest reruns tests. The test runner will wait for it to complete before executing tests. Note that you cannot destruct the `project` like `{ onTestsRerun }` because it relies on the context.
Copy file name to clipboardExpand all lines: docs/config/sequence.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ Sharding is happening before sorting, and only if `--shard` option is provided.
26
26
27
27
If [`sequencer.groupOrder`](#grouporder) is specified, the sequencer will be called once for each group and pool.
28
28
29
-
## groupOrder
29
+
## sequence.groupOrder
30
30
31
31
-**Type:**`number`
32
32
-**Default:**`0`
@@ -97,7 +97,7 @@ Tests in these projects will run in this order:
97
97
98
98
If you want files and tests to run randomly, you can enable it with this option, or CLI argument [`--sequence.shuffle`](/guide/cli).
99
99
100
-
Vitest usually uses cache to sort tests, so longrunning tests start earlier - this makes tests run faster. If your files and tests will run in random order you will lose this performance improvement, but it may be useful to track tests that accidentally depend on another run previously.
100
+
Vitest usually uses cache to sort tests, so long-running tests start earlier, which makes tests run faster. If your files and tests run in random order, you will lose this performance improvement, but it may be useful to track tests that accidentally depend on another test run previously.
Copy file name to clipboardExpand all lines: docs/config/setupfiles.md
+14-8Lines changed: 14 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,33 +7,39 @@ outline: deep
7
7
8
8
-**Type:**`string | string[]`
9
9
10
-
Path to setup files. They will be run before each test file.
10
+
Paths to setup files resolved relative to the [`root`](/config/root). They will run before each _test file_ in the same process. By default, all test files run in parallel, but you can configure it with [`sequence.setupFiles`](/config/sequence#sequence-setupfiles) option.
11
+
12
+
Vitest will ignore any exports from these files.
13
+
14
+
:::warning
15
+
Note that setup files are executed in the same process as tests, unlike [`globalSetup`](/config/globalsetup) that runs once in the main thread before any test worker is created.
16
+
:::
11
17
12
18
:::info
13
19
Editing a setup file will automatically trigger a rerun of all tests.
14
20
:::
15
21
16
-
You can use `process.env.VITEST_POOL_ID` (integer-like string) inside to distinguish between workers.
22
+
If you have a heavy process running in the background, you can use `process.env.VITEST_POOL_ID` (integer-like string) inside to distinguish between workers and spread the workload.
17
23
18
-
:::tip
19
-
Note, that if you are running [`--isolate=false`](#isolate), this setup file will be run in the same global scope multiple times. Meaning, that you are accessing the same global object before each test, so make sure you are not doing the same thing more than you need.
20
-
:::
24
+
:::warning
25
+
If [isolation](/config/isolate) is disabled, imported modules are cached, but the setup file itself is executed again before each test file, meaning that you are accessing the same global object before each test file. Make sure you are not doing the same thing more than necessary.
0 commit comments