test-fixture-creation

Test Fixture Creation

Guidelines for creating test fixtures that work with Bulwark's hook-based automation and avoid bias that could compromise testing.

---

When to Use This Skill

Load this skill when:

• Creating fixtures for manual testing of skills or agents
• Setting up E2E test scenarios that require hook automation
• Building code samples with deliberate issues for LLM review

DO NOT use for:

• Unit test fixtures (those can be isolated in tests/fixtures/)
• Mock data for automated tests
• Documentation examples

---

Core Principles

1. No Bias in Fixtures

CRITICAL: Fixtures must not contain any indicators that they are test fixtures.

Forbidden	Why	Alternative
test-*.ts, *-fixture.ts	Filename reveals intent	user-service.ts, data-processor.ts
// This is a test file	Comment reveals intent	No explanatory comments
// Intentional bug here	Points to the issue	Let LLM discover it
fixture/, test-data/	Directory name reveals intent	scripts/components/, lib/
FIXME, TODO: test	Markers reveal intent	Remove all markers

Why this matters: When Claude knows code is a test fixture, it may:

• Skip hook automation ("this is just a test")
• Ignore pipeline suggestions
• Produce different results than real code review

2. Project Infrastructure Integration

Fixtures must be placed within project infrastructure to enable hook automation.

Required for hooks to fire:

• Code must be in directories covered by tsconfig.json include paths
• Project must have working just typecheck and just lint recipes
• Fixtures must pass Phase 1 checks

Placement Strategy:

PROJECT_ROOT/
├── scripts/
│   ├── components/     ← Place fixtures here
│   │   ├── user-service.ts
│   │   ├── data-processor.ts
│   │   └── workflow-handler.ts
│   └── lib/            ← Supporting stubs
│       ├── database.ts
│       └── logger.ts

3. Fixtures Must Pass Phase 1