Skip to main content

vitest-testing

Write or review Vitest tests with clear behaviour-focused assertions, appropriate globals/imports, file snapshots for terminal output, and readable fixture setup. Use when adding tests, fixing Vitest failures, or improving TypeScript test quality.

소스 정보

저장소
ryoppippi/dotfiles
최근 소스 활동
2026년 6월 13일 22:50
감지된 SKILL.md 언어
영어
스타
268
포크
5

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
vitest-testing
description
Write or review Vitest tests with clear behaviour-focused assertions, appropriate globals/imports, file snapshots for terminal output, and readable fixture setup. Use when adding tests, fixing Vitest failures, or improving TypeScript test quality.
# Vitest Testing Use the `tdd` skill when the task is a logic change or bug fix that should start with a failing test. This skill covers Vitest-specific test shape and review rules. ## Setup - Check `vitest.config.*` before assuming globals are enabled. - If globals are enabled, use `describe`, `it`, `expect`, `vi`, `beforeEach`, and `assert` directly without importing them. - If globals are not enabled, import only the Vitest APIs used by the file. - Avoid `await import()` and other dynamic imports in tests unless the behaviour under test is dynamic loading. - Use `vi.stubEnv()` instead of mutating `process.env` directly. ## Readability - Test one behaviour per `it`. - Name tests after observable behaviour, not implementation details. - Avoid `try`/`catch` for expected failures. Use `expect(...).toThrow()`, `await expect(...).rejects`, or explicit Result failure assertions. - Avoid `if` branches inside test bodies. Split behaviours into separate tests or use `it.each` for table-driven cases. - KISS > DRY: do not over-DRY tests. Keep repeated setup inline when it makes the behaviour easier to read. - Keep assertions in the test unless a helper name is clearer than the assertion it hides. - Use `assert` to make preconditions explicit and narrow nullable values instead of using non-null assertions. ## Output Tests - Prefer JSON assertions for structured behaviour. - Use file snapshots with `toMatchFileSnapshot` for human-readable CLI/table output so layout changes are reviewable. - For responsive terminal output, capture or set the terminal width used by the command. ## Examples Expected failure: ```ts it('rejects invalid config', async () => { await expect(loadConfig('bad.json')).rejects.toThrow(Error); }); ``` Table-driven case: ```ts it.each([ ['daily', '2026-05-16'], ['monthly', '2026-05'], ])('groups %s rows by period', (reportType, expectedPeriod) => { const rows = groupUsage(reportType, usage); expect(rows[0]?.period).toBe(expectedPeriod); }); ``` Narrowing with `assert`: ```ts it('returns the first row', () => { const rows = getRows(); const firstRow = rows[0]; assert.isDefined(firstRow, 'expected at least one row'); expect(firstRow.id).toBe('row-1'); }); ```
GitHub에서 보기