
Testing
- 32 installs
- 217 repo stars
- Updated March 19, 2026
- poteto/noodle
testing is a Claude Code skill for testing & qa.
About
testing is a Claude Code skill for testing & qa. It helps solo builders move faster with AI-assisted development.
- testing
- Testing & QA
- AI-coding skill
Testing by the numbers
- 32 all-time installs (skills.sh)
- Ranked #1,340 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/poteto/noodle --skill testingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 32 |
|---|---|
| repo stars | ★ 217 |
| Last updated | March 19, 2026 |
| Repository | poteto/noodle ↗ |
How do I helps with testing & qa tasks.?
Helps with testing & qa tasks.
Who is it for?
Best when you're working on testing & qa and need structured help with testing.
Skip if: Teams with no testing & qa needs, or anyone wanting a generic chat assistant without this specific workflow.
When should I use this skill?
When you need to helps with testing & qa tasks., or when testing is a claude code skill for testing & qa.
What you get
Structured output aligned to testing: testing, Testing & QA.
Files
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 for full format, helper API, and code patterns.
Creating a New Fixture
./scripts/scaffold-fixture.sh <package-dir> <fixture-name> [state-count]Fill in the generated input.json/input.ndjson and expected.md, then:
pnpm fixtures:hash:syncBug Fixtures
See 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
# 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 ./tuiIntegration Tests
Long-running or external-dependency tests use testing.Short():
if testing.Short() {
t.Skip("skipping integration test in short mode")
}pnpm test:short skips these. pnpm test runs everything.
Fixture Test Reference
Directory Structure
package/testdata/
└── fixture-name/
├── expected.md # Expected output with YAML frontmatter
├── .noodle.toml # Optional config override
├── state-01/
│ ├── input.json # or input.ndjson
│ └── .noodle/ # Runtime state (queue.json, etc.)
└── state-02/ # Additional states numbered sequentiallyexpected.md Format
The file starts with YAML frontmatter delimited by ---, then markdown sections containing fenced JSON blocks.
Frontmatter fields:
--- schema_version: 1 expected_failure: false bug: false source_hash: pending ---
Sections (as H2 headings with fenced json blocks):
## Expected— Expected output (format varies by package)## Expected Error— Error expectations (optional)## Runtime Dump— Loop package uses this for multi-state transitions
Frontmatter Fields
| Field | Type | Purpose |
|---|---|---|
schema_version | int | Always 1 |
expected_failure | bool | Test expects an error |
bug | bool | Known failing test — requires expected_failure: true |
source_hash | string | SHA256 of inputs, auto-synced by pnpm fixtures:hash:sync |
Marking a Fixture as a Known Bug
Set both fields in frontmatter:
expected_failure: true
bug: trueAdd a placeholder ## Expected Error section with JSON body {"any": true}.
Verify it appears in pnpm bugs.
Scaffold Script
./scripts/scaffold-fixture.sh <package-dir> <fixture-name> [state-count]
# Examples:
./scripts/scaffold-fixture.sh loop my-new-test 2
./scripts/scaffold-fixture.sh parse edge-case-input 1Creates the directory, empty input files, and expected.md with source_hash: pending. Runs fixturehash sync automatically.
Recording Loop Fixtures
# Record new expected output
pnpm fixtures:loop:record
# Or manually:
NOODLE_LOOP_FIXTURE_MODE=record go test ./loop -run TestLoopDirectoryFixtures -count=1After recording, sync hashes:
pnpm fixtures:hash:syncTest Helper API (internal/testutil/fixturedir)
// Discover and load
inventory := fixturedir.LoadInventory(t, "testdata")
// Validate structure
fixturedir.AssertValidFixtureRoot(t, "testdata")
// Parse state data
input := fixturedir.ParseStateJSON[MyInput](t, state, "input.json")
// Get expected section
expected := fixturedir.MustSection(t, fixtureCase, "Expected")
// Assert errors
fixturedir.AssertError(t, "context", err, fixtureCase.ExpectedError)Typical Fixture Test Pattern
func TestDirectoryFixtures(t *testing.T) {
fixturedir.AssertValidFixtureRoot(t, "testdata")
inventory := fixturedir.LoadInventory(t, "testdata")
for _, fc := range inventory.Cases {
fc := fc
t.Run(fc.Name, func(t *testing.T) {
state := fc.States[0]
input := fixturedir.ParseStateJSON[MyType](t, state, "input.json")
actual, err := MyFunction(input)
fixturedir.AssertError(t, "test", err, fc.ExpectedError)
if fc.ExpectedError != nil {
return
}
expected := fixturedir.MustSection(t, fc, "Expected")
// ... compare actual vs expected
})
}
}Related skills
FAQ
What does testing do?
testing is a Claude Code skill for testing & qa.
When should I use testing?
When you need to helps with testing & qa tasks., or when testing is a claude code skill for testing & qa.
What are the main capabilities?
testing; Testing & QA; AI-coding skill.