E2E Test Coverage Report
Guidelines for maintaining dev/modern-tools/rspack/E2E_COVERAGE.md — a single-page report of what every E2E app and skeleton tests.
When to Update
| Trigger |
Action |
New app added to apps/ |
Add a subsection under Apps with a coverage table |
New skeleton added to skeleton.test.js |
Add a row to the Skeletons table |
| New npm package imported for compatibility testing |
Add an entry under NPM Package Compatibility with the package name, file, and reason |
| New custom assertion added to a test file |
Add a row to that app's coverage table |
| New feature tested across multiple apps |
Add a row to the Feature Coverage Matrix |
| App or skeleton removed |
Remove its entries from all sections |
Report Structure
The report has five sections, in this order:
- Test Lifecycle — the phases every app/skeleton goes through (init, run, prod, test, test once, build) and what default assertions apply
- Apps — one subsection per
apps/<name>/ with a short description and a | What is covered | Phase | table
- Skeletons — single table with one row per skeleton (
| Skeleton | Port | Language | Extra coverage |)
- NPM Package Compatibility — grouped by app, each entry has the package name, file path, and why it's included (ESM-only, native bindings, subpath exports, etc.)
- Feature Coverage Matrix — cross-reference table (
| Feature | Apps | Skeletons |) showing where each capability is tested
How to Gather Information
For each app or skeleton, check these sources:
| Source |
What to look for |
<name>.test.js |
Test helper used, options (env, configFile, buildDir, testFullApp, checkBundleFilePaths), all customAssertions callbacks and what they assert |
skeleton.test.js |
The testMeteorSkeleton({ skeletonName: '<name>' }) block for that skeleton |
apps/<name>/server/main.js |
npm imports with comments explaining why (ESM-only, native bindings, etc.) |
apps/<name>/imports/ |
Shared code with special imports (node: protocol, JSX packages) |
apps/<name>/rspack.config.* |
Custom config features (compileWithRspack, compileWithMeteor, disablePlugins, custom rules) |
apps/<name>/package.json |
Dependencies that exist solely for compatibility testing |
Writing Guidelines
- Keep descriptions short — one line per table row
- Use the phase names from the lifecycle table: Init, Run, Prod, Test, Build, All
- For npm packages, always state the reason (what module format issue it validates)
- Don't duplicate info between the per-app table and the feature matrix — the app table has detail, the matrix has the cross-reference
- When an env var is set in a test file, note it as
All (env prefix) in the phase column
1---2name: e2e-coverage3description: Use when adding, modifying, or reviewing E2E test apps/skeletons to keep the test coverage report up to date.4---56# E2E Test Coverage Report78Guidelines for maintaining `dev/modern-tools/rspack/E2E_COVERAGE.md` — a single-page report of what every E2E app and skeleton tests.910## When to Update1112| Trigger | Action |13|---------|--------|14| New app added to `apps/` | Add a subsection under **Apps** with a coverage table |15| New skeleton added to `skeleton.test.js` | Add a row to the **Skeletons** table |16| New npm package imported for compatibility testing | Add an entry under **NPM Package Compatibility** with the package name, file, and reason |17| New custom assertion added to a test file | Add a row to that app's coverage table |18| New feature tested across multiple apps | Add a row to the **Feature Coverage Matrix** |19| App or skeleton removed | Remove its entries from all sections |2021## Report Structure2223The report has five sections, in this order:24251. **Test Lifecycle** — the phases every app/skeleton goes through (init, run, prod, test, test once, build) and what default assertions apply262. **Apps** — one subsection per `apps/<name>/` with a short description and a `| What is covered | Phase |` table273. **Skeletons** — single table with one row per skeleton (`| Skeleton | Port | Language | Extra coverage |`)284. **NPM Package Compatibility** — grouped by app, each entry has the package name, file path, and why it's included (ESM-only, native bindings, subpath exports, etc.)295. **Feature Coverage Matrix** — cross-reference table (`| Feature | Apps | Skeletons |`) showing where each capability is tested3031## How to Gather Information3233For each app or skeleton, check these sources:3435| Source | What to look for |36|--------|-----------------|37| `<name>.test.js` | Test helper used, options (`env`, `configFile`, `buildDir`, `testFullApp`, `checkBundleFilePaths`), all `customAssertions` callbacks and what they assert |38| `skeleton.test.js` | The `testMeteorSkeleton({ skeletonName: '<name>' })` block for that skeleton |39| `apps/<name>/server/main.js` | npm imports with comments explaining why (ESM-only, native bindings, etc.) |40| `apps/<name>/imports/` | Shared code with special imports (`node:` protocol, JSX packages) |41| `apps/<name>/rspack.config.*` | Custom config features (`compileWithRspack`, `compileWithMeteor`, `disablePlugins`, custom rules) |42| `apps/<name>/package.json` | Dependencies that exist solely for compatibility testing |4344## Writing Guidelines4546- Keep descriptions short — one line per table row47- Use the phase names from the lifecycle table: Init, Run, Prod, Test, Build, All48- For npm packages, always state the **reason** (what module format issue it validates)49- Don't duplicate info between the per-app table and the feature matrix — the app table has detail, the matrix has the cross-reference50- When an env var is set in a test file, note it as `All (env prefix)` in the phase column
meteor