unit-test

스타1

포크0

업데이트2026년 8월 2일 05:07

Use when adding or updating unit tests for create-vibe-start CLI modules, especially Vitest tests that must isolate prompts, shell commands, platform detection, and package imports from real external resources.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

bichikim

bichikim/create-vibe-start

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Unit Testing

Core Rules

Mock external resources at the import boundary: prompt packages, shell runners, command lookup, platform detection, filesystem/network access, and process exits.
Keep unit tests focused on observable behavior: returned status objects, called command arguments, prompt choices, and CLI options.
Simulate gh, vercel, codex, package managers, login flows, and network requests with mocks in unit tests.
Prefer small fixtures and table-style cases when the same setup flow has multiple outcomes.
Add integration tests when broader confidence is needed, and label that boundary clearly.

File Location

Put each unit test in a __tests__ folder next to the file under test.
Name the test after the target file with a .spec.ts suffix. Example: foo.ts -> __tests__/foo.spec.ts.
Keep unit tests colocated with the target module under its nearest __tests__ folder.
Split multi-target tests into one spec per target file when each target has its own behavior.

Vitest Pattern

Use vi.mock(...) before importing the module under test when the module reads mocked imports at load time.
Prefer Vitest tools such as vi.spyOn(...) for mocking runtime values; do not directly rewrite globals with Object.defineProperty(...) unless no test helper can model the behavior.
Use dynamic await import(...) after mocks for step configuration tests.
Reset module state with vi.resetModules() when testing environment-sensitive modules.
Assert command arrays exactly so install/login regressions are easy to catch.

Test Shape

Utilities: verify success/failure branches by mocking their direct dependency.
Steps: verify the setup options passed to the shared setup helper.
Shared orchestration: cover ready, skipped, failed, install, login, and cancel-like branches.
CLI entry: test argument handling without starting real prompts or external commands.

이 저장소의 다른 Skills

같은 저장소

skill-diet

bichikim/create-vibe-start

Reduce an existing Codex skill to its minimum useful form, extract on-demand context into linked sibling files, or decide that the skill should be deleted. Use when the user asks to diet, slim, trim, simplify, minimize, reevaluate, or remove bloat from a skill while preserving its trigger behavior, tone, safety constraints, and practical usefulness.

2026-08-021

new-pr

bichikim/create-vibe-start

Create a GitHub pull request from the current branch—commit uncommitted changes, push, and open a PR against main with an auto-generated title and Summary/Testing body sections.

2026-08-021

critical-review

bichikim/create-vibe-start

Review code for correctness risks, maintainability, security, and lifecycle issues with severity-tagged findings.

2026-05-171

update-pr

bichikim/create-vibe-start

Update an existing GitHub pull request for the current branch—commit and push latest changes, then refresh the PR title and body from the full diff against main.

2026-05-171

deep-interview

bichikim/create-vibe-start

Interview the user with Socratic questions to turn an ambiguous request into actionable requirements. Use when the user asks for a deep-interview, requirement clarification, or help organizing their thoughts, or when the goal, scope, constraints, or definition of done are unclear. Do not use when the request is already concrete, or for low-value work like typo fixes, small config tweaks, or test top-ups.

2026-05-131

project-skill-generating

bichikim/create-vibe-start

Use when creating or updating project-specific Codex skills for create-vibe-start, especially skills stored under .agents/skills with concise SKILL.md instructions and progressively loaded reference files.

2026-05-041

Unit Testing

Core Rules

Mock external resources at the import boundary: prompt packages, shell runners, command lookup, platform detection, filesystem/network access, and process exits.

Keep unit tests focused on observable behavior: returned status objects, called command arguments, prompt choices, and CLI options.

Simulate gh, vercel, codex, package managers, login flows, and network requests with mocks in unit tests.

Prefer small fixtures and table-style cases when the same setup flow has multiple outcomes.

Add integration tests when broader confidence is needed, and label that boundary clearly.

File Location

Put each unit test in a __tests__ folder next to the file under test.

Name the test after the target file with a .spec.ts suffix. Example: foo.ts -> __tests__/foo.spec.ts.

Keep unit tests colocated with the target module under its nearest __tests__ folder.

Split multi-target tests into one spec per target file when each target has its own behavior.

Vitest Pattern

Use vi.mock(...) before importing the module under test when the module reads mocked imports at load time.

Prefer Vitest tools such as vi.spyOn(...) for mocking runtime values; do not directly rewrite globals with Object.defineProperty(...) unless no test helper can model the behavior.

Use dynamic await import(...) after mocks for step configuration tests.

Reset module state with vi.resetModules() when testing environment-sensitive modules.

Assert command arrays exactly so install/login regressions are easy to catch.

Test Shape

Utilities: verify success/failure branches by mocking their direct dependency.

Steps: verify the setup options passed to the shared setup helper.

Shared orchestration: cover ready, skipped, failed, install, login, and cancel-like branches.

CLI entry: test argument handling without starting real prompts or external commands.

name	unit-test
description	Use when adding or updating unit tests for create-vibe-start CLI modules, especially Vitest tests that must isolate prompts, shell commands, platform detection, and package imports from real external resources.