Testing Strategies
Relevant source files
The following files were used as context for generating this wiki page:
The Svelte Effect Runtime (SER) project employs a multi-tiered testing and validation strategy to ensure the integrity of its core runtime, compiler transforms, language server integrations, and grammars. Because SER introduces custom syntax—such as <script effect> and direct yield* in markup—standard Svelte validation tools (like svelte-check) are considered non-authoritative. Instead, the project prioritizes tests that run through the actual Vite pipeline or specialized runtime test suites.
Testing is distributed across the workspace, with specific test suites residing in the .tests directory, mirroring the package structure. The primary goals are to verify that generated code matches expected shapes, user-facing behavior remains consistent, and boundary conditions involving SvelteKit or Effect control flow are handled correctly.
Sources: CONTRIBUTING.md:46-55, skills/svelte-effect-runtime/SKILL.md:37-41, skills/svelte-effect-runtime/references/validation.md:1-10
Core Testing Principles
The project follows strict guidelines regarding the focus and execution of tests:
- Fixture-Based Reproduction: For bugs involving SvelteKit or Effect control flow, developers are encouraged to use small fixtures that reproduce specific boundaries rather than large application-shaped tests.
- Dual-Assertion Strategy: When a transform modifies generated code, tests must assert both on the important generated shape and the user-facing behavior.
- Vite-First Validation: Preferred validation methods are those that utilize the project's Vite pipeline, as plain Svelte tooling does not run the SER transform and may report false positives for valid SER source.
Sources: CONTRIBUTING.md:67-73, skills/svelte-effect-runtime/references/validation.md:3-6
Test Execution Flow
The following diagram illustrates the workflow for running different levels of tests within the monorepo.
The testing workflow utilizes pnpm through Corepack to trigger Vitest across specific module directories or the entire workspace.
Sources: CONTRIBUTING.md:46-55, package.json:20
Categorized Test Suites
Tests are organized under the .tests directory and mapped to their respective packages in modules/.
| Test Suite Location | Target Package | Scope of Verification |
|---|---|---|
.tests/svelte-effect-runtime/runtime | modules/svelte-effect-runtime | Runtime logic, compiler transforms, and server helpers. |
.tests/svelte-effect-runtime-grammars/runtime | modules/svelte-effect-runtime-grammars | TextMate and tree-sitter grammar accuracy. |
.tests/svelte-effect-runtime-language-server/runtime | modules/svelte-effect-runtime-language-server | Language server integration and document mapping. |
.tests/svelte-effect-runtime-vsix/runtime | modules/svelte-effect-runtime-vsix | VS Code extension activation and behavior. |
Sources: CONTRIBUTING.md:57-65
Runtime and Compiler Tests
These are the most critical tests as they verify the yield* transform logic. The repository provides a specific command for running these in a standalone environment:
cd .tests/svelte-effect-runtime
deno test --no-check -A runtime/
Sources: skills/svelte-effect-runtime/references/validation.md:12-15
Workspace Validation Commands
In addition to unit and integration tests, the project uses a series of validation scripts to ensure code quality and consistency across the workspace.
| Command | Tool | Purpose |
|---|---|---|
pnpm run test | Vitest | Runs the full test suite across all packages. |
pnpm run build | Vite+ | Full workspace build to verify package exports and VSIX packaging. |
pnpm run check | TypeScript | Runs type checks (e.g., tsc --noEmit). |
pnpm run lint | Vite+ (vp) | Lints the entire workspace including build scripts and tests. |
pnpm run smoke:runtime | Node | Executes a smoke test on the runtime build output. |
Sources: package.json:6-21, CONTRIBUTING.md:31-44, modules/svelte-effect-runtime-grammars/package.json:33-36
Handling Tooling Bias
A significant portion of the testing strategy involves managing "Tooling Bias." Because SER syntax is a compile-time transform, many standard tools will report errors that are invalid in the context of an SER-enabled project.
False Positive Management
The following components are frequently flagged by plain Svelte tools but are considered valid and must be verified by SER-specific tests:
- Script Attributes:
<script effect>or<script lang="ts" effect>. - Markup Syntax: Direct
yield*inside.sveltemarkup or declaration tags. - Event Handlers: Yield-first handlers like
onclick={yield* save(id)}.
Sources: skills/svelte-effect-runtime/SKILL.md:50-55, skills/svelte-effect-runtime/references/validation.md:17-23
Validation Hierarchy
The hierarchy prioritizes the Vite pipeline and internal runtime tests over generic Svelte tooling to ensure that SER-specific syntax is correctly processed.
Sources: skills/svelte-effect-runtime/SKILL.md:50-59, skills/svelte-effect-runtime/references/validation.md:1-10
Conclusion
Testing in Svelte Effect Runtime is a specialized process that bypasses traditional Svelte validation in favor of a Vite-integrated approach. By maintaining distinct test suites for the runtime, grammars, and language server, and by prioritizing small, focused fixtures for bug reproduction, the project ensures that the complex yield* transformations remain robust across various SvelteKit and Effect environments.