一键在 Manus 中运行任何 Skill

vitest-testing

星标4

分支1

更新时间2026年5月6日 18:27

Guides Vitest-based unit and integration tests with vi mocks, Arrange-Act-Assert, fake timers for Date, HTTP endpoint integration tests without supertest, use-case and domain coverage. Do not use for Jest-centric projects or Sinon as primary mocking.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

rodrigobranas

rodrigobranas/f_ia_m1_3

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Vitest testing

Procedures

When authoring or refactoring tests

Use Vitest for scenarios and expectations (describe, it, expect). Use Vitest vi for mocks, spies, and stubs (vi.fn, vi.spyOn, vi.mock, vi.useFakeTimers, and related APIs).
Do not use Jest or Sinon as the primary mocking stack for those roles.
Run tests via npm run test (script invokes Vitest) or npx vitest, matching the repository setup.
Place tests under the folder pattern appropriate to the stack; keep file extensions aligned with tooling (for example .test.ts / .spec.ts).
Avoid dependencies between tests so each example runs independently.
Structure each test using Arrange–Act–Assert or Given–When–Then for clarity.
When behavior depends on Date relative to assertions, configure Vitest fake timers and fixed system time; restore real timers in afterEach.
When tests touch HTTP, databases, messaging, filesystems, or other externals, name or organize them explicitly as integration tests.
Add HTTP endpoint tests only as integration tests; omit Supertest-style libraries per project policy.
Keep HTTP endpoint tests scoped to principal and alternate flows (status codes and error messages); push business-rule permutations down to use-case tests.
Cover all use cases: primary paths plus at least one alternate path that throws; mock externals via vi.fn or vi.mock.
Cover domain logic thoroughly at unit level without external dependencies.
Aim for one observable behavior per test; keep descriptions concise and intent-revealing.
Maintain coverage proportionate to new or changed logic; align expectations with behavior that materially matters.
Close DB or messaging handles after suites or cases when the stack requires teardown.
Use beforeEach from Vitest when setup is repeatable; use afterEach when releasing connections or mocks.

Error Handling

When timer-related flakes appear around Date or timeouts, revisit fake timer lifecycle (beforeEach / afterEach) and deterministic clock setup.
When integration suites pollute shared state, isolate fixtures and ensure teardown resets global mocks and connections.

同仓库更多 Skills

同仓库

code-standards-en

rodrigobranas/f_ia_m1_3

Specifies English identifiers, casing conventions, verb-led functions, parameterized objects over long arg lists, CQS separation, guarded early returns, split boolean-flag behaviors, sizing limits for methods and classes, minimal comments. Do not use when localized naming is required by product policy.

2026-05-064

express-rest-http

rodrigobranas/f_ia_m1_3

Maps Express endpoints to REST-ish resources with POST action verbs for mutations, mandatory security middleware, canonical status codes, OpenAPI documentation, pagination limit and offset, partial field queries, native fetch for outbound HTTP. Do not use when replacing Express with another server framework.

2026-05-064

nodejs-typescript-conventions

rodrigobranas/f_ia_m1_3

Enforces TypeScript-only source, npm for scripts and deps, ESM import and export defaults, async await over raw then chains, no any types, minimal let usage, private or readonly class fields, functional collection helpers. Do not use for plain JavaScript codebases or non-npm package managers.

2026-05-064

react-frontend-conventions

rodrigobranas/f_ia_m1_3

Constrains functional React with TypeScript and Tailwind: local state colocation, explicit props instead of spreads, Context for cross-cutting state, useMemo for heavy derivations, use-prefixed hooks, component tests. Do not use for class components, styled-components, or non-Tailwind styling stacks.

2026-05-064

repo-folder-structure

rodrigobranas/f_ia_m1_3

Defines hybrid feature-based frontend layout under src plus backend controllers-services-data layering and HTTP flow direction. Applies when creating routes, pages, features, or backend modules for consistency. Do not use for monorepo-wide policies outside this template or frameworks that forbid this layout.

2026-05-064

skill-best-practices

rodrigobranas/f_ia_m1_3

Authors and structures professional-grade agent skills following the agentskills.io spec. Use when creating new skill directories, drafting procedural instructions, or optimizing metadata for discoverability. Don't use for general documentation, non-agentic library code, or README files.

2026-05-064

name	vitest-testing
description	Guides Vitest-based unit and integration tests with vi mocks, Arrange-Act-Assert, fake timers for Date, HTTP endpoint integration tests without supertest, use-case and domain coverage. Do not use for Jest-centric projects or Sinon as primary mocking.

Vitest testing

Procedures

When authoring or refactoring tests

Use Vitest for scenarios and expectations (describe, it, expect). Use Vitest vi for mocks, spies, and stubs (vi.fn, vi.spyOn, vi.mock, vi.useFakeTimers, and related APIs).
Do not use Jest or Sinon as the primary mocking stack for those roles.
Run tests via npm run test (script invokes Vitest) or npx vitest, matching the repository setup.
Place tests under the folder pattern appropriate to the stack; keep file extensions aligned with tooling (for example .test.ts / .spec.ts).
Avoid dependencies between tests so each example runs independently.
Structure each test using Arrange–Act–Assert or Given–When–Then for clarity.
When behavior depends on Date relative to assertions, configure Vitest fake timers and fixed system time; restore real timers in afterEach.
When tests touch HTTP, databases, messaging, filesystems, or other externals, name or organize them explicitly as integration tests.
Add HTTP endpoint tests only as integration tests; omit Supertest-style libraries per project policy.
Keep HTTP endpoint tests scoped to principal and alternate flows (status codes and error messages); push business-rule permutations down to use-case tests.
Cover all use cases: primary paths plus at least one alternate path that throws; mock externals via vi.fn or vi.mock.
Cover domain logic thoroughly at unit level without external dependencies.
Aim for one observable behavior per test; keep descriptions concise and intent-revealing.
Maintain coverage proportionate to new or changed logic; align expectations with behavior that materially matters.
Close DB or messaging handles after suites or cases when the stack requires teardown.
Use beforeEach from Vitest when setup is repeatable; use afterEach when releasing connections or mocks.

Error Handling

When timer-related flakes appear around Date or timeouts, revisit fake timer lifecycle (beforeEach / afterEach) and deterministic clock setup.
When integration suites pollute shared state, isolate fixtures and ensure teardown resets global mocks and connections.