Help us improve
Share bugs, ideas, or general feedback.
From bee
Guides TDD cycles (red-green-refactor), outside-in double-loop architecture, test isolation, and naming. Useful when writing test plans or reviewing test quality.
npx claudepluginhub incubyte/ai-plugins --plugin beeHow this skill is triggered — by the user, by Claude, or both
Slash command
/bee:tdd-practicesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The fundamental TDD cycle:
Guides the RED-GREEN-REFACTOR cycle for test-driven development, including AAA pattern, test prioritization, and anti-patterns. Useful when writing tests before code or implementing new features.
Test-Driven Development methodology: write tests first, Red-Green-Refactor cycle, test lists, outside-in development, and incremental design.
Share bugs, ideas, or general feedback.
The fundamental TDD cycle:
Each cycle should take minutes, not hours. Small cycles build confidence and momentum.
For architectures with clear layer boundaries:
Outer loop: Integration test at the boundary (HTTP request in, response out). Stays RED until all inner layers are wired.
Inner loop: Unit tests for each layer, working inward:
Key insight: the mocks you write in domain tests define the contracts. Those contracts become port interfaces. Architecture emerges from the tests.
Test behavior, not implementation. A good test survives a refactor. If you rename a private method and a test breaks, the test was testing implementation.
Good test: "When a user submits a valid order, the total reflects the discount." Bad test: "The calculateDiscount private method returns 0.15 for orders over $100."
Each test should have one reason to fail. If a test can fail for three different reasons, it's three tests pretending to be one.
Test names describe the scenario:
rejects_expired_discount_codesapplies_bulk_pricing_for_orders_over_ten_itemsreturns_404_when_product_not_foundUnit tests should not depend on:
Use test doubles (mocks, stubs, fakes) to isolate the unit under test. But don't mock what you don't own — wrap external dependencies in your own adapter and mock that.
Unit tests: Fast, isolated, test one behavior. Run hundreds per second. Use for business logic, validation, data transformation.
Integration tests: Slower, test real connections. Use for database queries, API calls, file I/O, end-to-end user journeys.
The split: Most of your tests should be unit tests. Integration tests confirm the wiring works. A typical ratio: 80% unit, 20% integration.
When to go integration-first: If the feature is primarily about connecting things (CRUD endpoint, data pipeline, API gateway), start with an integration test. If the feature has complex business rules, start with unit tests for the rules.