testing
Test-driven development workflow for Noodle. Use when testing changes, writing tests, fixing bugs, creating fixtures, or running the test suite. Triggers: "test", "write a test", "fix this bug", "add a fixture", "run tests", "TDD", or any task involving verification of code changes.
소스 정보
- 저장소
- poteto/noodle
- 최근 소스 활동
- 2026년 3월 19일 04:43
- 감지된 SKILL.md 언어
- 영어
- 스타
- 281
- 포크
- 16
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
파일 탐색기
2 개 파일SKILL.md 표시 중
SKILL.md
소스 지침 · 읽기 전용 미리보기- name
- testing
- description
- Test-driven development workflow for Noodle. Use when testing changes, writing tests, fixing bugs, creating fixtures, or running the test suite. Triggers: "test", "write a test", "fix this bug", "add a fixture", "run tests", "TDD", or any task involving verification of code changes.
# Testing
Test-driven by default. Prove the problem before solving it.
## Core Workflow: Bug First
1. **Reproduce** — Run the failing scenario and observe the actual behavior
2. **Write a failing test** — Minimal reproduction as a test case
3. **Commit the failing test** — Use `Skill(commit)` with message like `test: reproduce #issue-description`
4. **Fix the code** — Only now attempt the fix
5. **Verify** — Run `pnpm test` and confirm the test passes
6. **Commit the fix** — Separate commit from the test
This applies to all bug fixes. The failing test proves the bug exists and prevents regressions.
## Fixture Tests
Noodle uses directory-based fixtures in `testdata/`. Read [references/fixtures.md](references/fixtures.md) for full format, helper API, and code patterns.
### Creating a New Fixture
```sh
./scripts/scaffold-fixture.sh <package-dir> <fixture-name> [state-count]
```
Fill in the generated `input.json`/`input.ndjson` and `expected.md`, then:
```sh
pnpm fixtures:hash:sync
```
### Bug Fixtures
See [references/fixtures.md](references/fixtures.md) for full bug fixture format (frontmatter fields, expected error sections, and the fix workflow).
## Key Commands
| Command | Purpose |
|---------|---------|
| `pnpm test` | Run all tests |
| `pnpm test:short` | Skip integration tests |
| `pnpm check` | Full local CI (test + vet + lint + fixtures) |
| `pnpm bugs` | List fixtures marked as known bugs |
| `pnpm fixtures:loop` | Verify loop fixtures match expected |
| `pnpm fixtures:loop:record` | Regenerate loop fixture expected output |
| `pnpm fixtures:hash` | Verify fixture input hashes |
| `pnpm fixtures:hash:sync` | Update fixture input hashes |
| `pnpm vet` | Run `go vet` |
| `pnpm lint:arch` | Architecture lint (file sizes, legacy patterns) |
## Running Specific Tests
```sh
# Single package
go test ./loop
# Single test
go test ./loop -run TestLoopDirectoryFixtures
# Bypass cache
go test -count=1 ./parse
# With race detector
go test -race ./...
# Verbose
go test -v ./tui
```
## Integration Tests
Long-running or external-dependency tests use `testing.Short()`:
```go
if testing.Short() {
t.Skip("skipping integration test in short mode")
}
```
`pnpm test:short` skips these. `pnpm test` runs everything.
GitHub에서 보기