원클릭으로 Manus에서 모든 스킬 실행

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 저장소 열기 Creator 저장소 보기

다운로드

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.