Phase 1b: Rename all ~94 commands across 12 plugins to /<noun> <action> sub-command pattern. Git-flow consolidated from 8→5 commands (commit variants absorbed into --push/--merge/--sync flags). Dispatch files, name: frontmatter, and cross-reference updates for all plugins. Phase 2: Design documents for 8 new plugins in docs/designs/. Phase 3: Scaffold 8 new plugins — saas-api-platform, saas-db-migrate, saas-react-platform, saas-test-pilot, data-seed, ops-release-manager, ops-deploy-pipeline, debug-mcp. Each with plugin.json, commands, agents, skills, README, and claude-md-integration. Marketplace grows from 12→20. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.3 KiB
2.3 KiB
description
| description |
|---|
| Test design patterns for unit, integration, and e2e tests |
Test Patterns Skill
Overview
Standard test design patterns organized by test type. Use these as templates when generating tests.
Unit Test Patterns
Arrange-Act-Assert (AAA)
The default pattern for unit tests:
Arrange: Set up test data and dependencies
Act: Call the function under test
Assert: Verify the result matches expectations
- Keep Arrange minimal — only what this specific test needs
- Act should be a single function call
- Assert one logical concept (multiple assertions allowed if same concept)
Parameterized Tests
Use when testing the same logic with different inputs:
- pytest:
@pytest.mark.parametrize("input,expected", [...]) - Jest:
test.each([...])("description %s", (input, expected) => {...})
Best for: validation functions, parsers, formatters, math operations.
Exception Testing
Verify error conditions explicitly:
- pytest:
with pytest.raises(ValueError, match="expected message") - Jest:
expect(() => fn()).toThrow("expected message")
Always assert the exception type AND message content.
Integration Test Patterns
Setup/Teardown
Use fixtures or beforeEach/afterEach for:
- Database connections and seeded data
- Temporary files and directories
- Mock server instances
- Environment variable overrides
Transaction Rollback
For database integration tests, wrap each test in a transaction that rolls back:
- Ensures test isolation without slow re-seeding
- pytest:
@pytest.fixture(autouse=True)with session-scoped DB and function-scoped transaction
E2E Test Patterns
Page Object Model
Encapsulate page interactions in reusable classes:
- One class per page or significant component
- Methods return page objects for chaining
- Selectors defined as class properties
- No assertions inside page objects
User Flow Pattern
Structure E2E tests as user stories:
- Setup — authenticate, navigate to starting point
- Action — perform the user's workflow steps
- Verification — check the final state
- Cleanup — reset any created data
Anti-Patterns to Avoid
- Testing implementation details instead of behavior
- Mocking the thing you are testing
- Tests that depend on execution order
- Assertions on exact error messages from third-party libraries
- Sleeping instead of waiting for conditions