Skip to content

docs(lifecycle): update lifecycle document format #9866

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
NoiseFan wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(lifecycle): update lifecycle document format #9866

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 17 additions & 17 deletions docs/guide/lifecycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,13 +11,13 @@ Understanding the test run lifecycle is essential for writing effective tests, d

A typical Vitest test run goes through these main phases:

1. **Initialization** - Configuration loading and project setup
2. **Global Setup** - One-time setup before any tests run
3. **Worker Creation** - Test workers are spawned based on the [pool](/config/pool) configuration
4. **Test File Collection** - Test files are discovered and organized
5. **Test Execution** - Tests run with their hooks and assertions
6. **Reporting** - Results are collected and reported
7. **Global Teardown** - Final cleanup after all tests complete
1. **Initialization:** Configuration loading and project setup
2. **Global Setup:** One-time setup before any tests run
3. **Worker Creation:** Test workers are spawned based on the [pool](/config/pool) configuration
4. **Test File Collection:** Test files are discovered and organized
5. **Test Execution:** Tests run with their hooks and assertions
6. **Reporting:** Results are collected and reported
7. **Global Teardown:** Final cleanup after all tests complete

Phases 4–6 run once for each test file, so across your test suite they will execute multiple times and may also run in parallel across different files when you use more than [1 worker](/config/maxworkers).

Expand Down Expand Up @@ -124,10 +124,10 @@ Test files are executed based on your configuration:

The execution follows this order:

1. **File-level code** - All code outside `describe` blocks runs immediately
2. **Test collection** - `describe` blocks are processed, and tests are registered as side effects of importing the test file
3. **[`aroundAll`](/api/hooks#aroundall) hooks** - Wrap around all tests in the suite (must call `runSuite()`)
4. **[`beforeAll`](/api/hooks#beforeall) hooks** - Run once before any tests in the suite
1. **File-level code:** All code outside `describe` blocks runs immediately
2. **Test collection:** `describe` blocks are processed, and tests are registered as side effects of importing the test file
3. **[`aroundAll`](/api/hooks#aroundall) hooks:** Wrap around all tests in the suite (must call `runSuite()`)
4. **[`beforeAll`](/api/hooks#beforeall) hooks:** Run once before any tests in the suite
5. **For each test:**
- [`aroundEach`](/api/hooks#aroundeach) hooks wrap around the test (must call `runTest()`)
- `beforeEach` hooks execute (in order defined, or based on [`sequence.hooks`](/config/sequence#sequence-hooks))
Expand All @@ -136,7 +136,7 @@ The execution follows this order:
- [`onTestFinished`](/api/hooks#ontestfinished) callbacks run (always in reverse order)
- If test failed: [`onTestFailed`](/api/hooks#ontestfailed) callbacks run
- Note: if `repeats` or `retry` are set, all of these steps are executed again
6. **[`afterAll`](/api/hooks#afterall) hooks** - Run once after all tests in the suite complete
6. **[`afterAll`](/api/hooks#afterall) hooks:** Run once after all tests in the suite complete

**Example execution flow:**

Expand Down Expand Up @@ -361,11 +361,11 @@ In watch mode, the lifecycle repeats with some differences:

Understanding the lifecycle helps optimize test performance:

- **Global setup** is ideal for expensive one-time operations (database seeding, server startup)
- **Setup files** run before each test file - avoid heavy operations here if you have many test files
- **`beforeAll`** is better than `beforeEach` for expensive setup that doesn't need isolation
- **Disabling [isolation](/config/isolate)** improves performance, but setup files still execute before each file
- **[Pool configuration](/config/pool)** affects parallelization and available APIs
- **Global setup:** is ideal for expensive one-time operations (database seeding, server startup)
- **Setup files:** run before each test file - avoid heavy operations here if you have many test files
- **`beforeAll`:** `beforeAll` is better than `beforeEach` for expensive setup that doesn't need isolation
- **Disabling [isolation](/config/isolate):** improves performance, but setup files still execute before each file
- **[Pool configuration](/config/pool):** affects parallelization and available APIs

For tips on how to improve performance, read the [Improving Performance](/guide/improving-performance) guide.

Expand Down
Loading