tdd-methodology
Test-driven development methodology with four test types - unit, integration, property, and e2e. Use when writing tests, planning test strategy, implementing features test-first, or verifying test coverage. Triggers when tests are mentioned, test files are being created, or test-first approach is needed.
What this skill does
# Test-Driven Development Methodology
Tests verify specifications are met. Write tests BEFORE implementation. Tests reference spec paragraph IDs for traceability.
## The TDD Cycle
```
┌──────────────────┐
│ 1. RED │ Write a failing test for spec requirement
├──────────────────┤
│ 2. GREEN │ Write minimal code to pass
├──────────────────┤
│ 3. REFACTOR │ Improve code, keep tests green
└──────────────────┘
```
## Four Test Types
### 1. Unit Tests
**Purpose**: Test individual functions/methods in isolation
**Location**: `tests/unit/`
**Characteristics**:
- Fast (ms per test)
- No I/O, no network, no filesystem
- Mock external dependencies
- One assertion focus per test
**Pattern**:
```
test_<function>_<scenario>_<expected>
```
**Example** (Rust):
```rust
#[test]
// @trace SPEC-03.07
fn test_validate_length_exceeds_max_returns_error() {
let input = "x".repeat(1025);
assert!(validate_length(&input).is_err());
}
```
**Example** (TypeScript):
```typescript
describe('validateLength', () => {
// @trace SPEC-03.07
it('returns error when input exceeds max length', () => {
const input = 'x'.repeat(1025);
expect(() => validateLength(input)).toThrow();
});
});
```
**Example** (Python):
```python
def test_validate_length_exceeds_max_returns_error():
"""@trace SPEC-03.07"""
input_str = 'x' * 1025
with pytest.raises(ValidationError):
validate_length(input_str)
```
### 2. Integration Tests
**Purpose**: Test component interactions, real dependencies
**Location**: `tests/integration/`
**Characteristics**:
- Slower (seconds per test)
- Real database, real filesystem, test containers
- Test boundaries between modules
- Setup/teardown for external state
**Pattern**:
```
test_<component>_<integration>_<scenario>
```
**Example** (Rust):
```rust
#[tokio::test]
// @trace SPEC-05.12
async fn test_auth_service_validates_against_database() {
let db = TestDb::new().await;
let auth = AuthService::new(db.pool());
let result = auth.authenticate(valid_credentials()).await;
assert!(result.is_ok());
}
```
### 3. Property Tests
**Purpose**: Test invariants hold across generated inputs
**Location**: `tests/property/`
**Characteristics**:
- Generates random inputs
- Finds edge cases automatically
- Tests properties, not specific values
- Shrinks failing cases to minimal examples
**Properties to test**:
- Roundtrip: `decode(encode(x)) == x`
- Idempotence: `f(f(x)) == f(x)`
- Invariants: `len(result) <= MAX_SIZE`
- Commutativity: `f(a, b) == f(b, a)`
**Example** (Rust with proptest):
```rust
proptest! {
#[test]
// @trace SPEC-02.01 - Encoding roundtrip
fn test_encode_decode_roundtrip(input: String) {
let encoded = encode(&input);
let decoded = decode(&encoded)?;
prop_assert_eq!(decoded, input);
}
}
```
**Example** (Python with Hypothesis):
```python
from hypothesis import given, strategies as st
@given(st.text())
def test_encode_decode_roundtrip(input_str):
"""@trace SPEC-02.01"""
encoded = encode(input_str)
decoded = decode(encoded)
assert decoded == input_str
```
**Example** (TypeScript with fast-check):
```typescript
import fc from 'fast-check';
// @trace SPEC-02.01
test('encode/decode roundtrip', () => {
fc.assert(fc.property(fc.string(), (input) => {
const encoded = encode(input);
const decoded = decode(encoded);
return decoded === input;
}));
});
```
### 4. End-to-End Tests
**Purpose**: Test complete user workflows
**Location**: `tests/e2e/`
**Characteristics**:
- Slowest (minutes per suite)
- Real environment, real data flows
- Test from user's perspective
- Critical paths only (expensive to maintain)
**Pattern**:
```
test_<user_journey>_<expected_outcome>
```
**Example**:
```typescript
// @trace SPEC-01.01 - Complete user registration flow
test('user can register and receive confirmation email', async () => {
await page.goto('/register');
await page.fill('#email', '[email protected]');
await page.fill('#password', 'SecurePass123!');
await page.click('button[type="submit"]');
await expect(page).toHaveURL('/welcome');
await expect(emailServer).toHaveReceivedEmail({
to: '[email protected]',
subject: /Welcome/
});
});
```
## Test Pyramid
```
╱╲
╱ ╲ E2E (few)
╱────╲ Critical user journeys
╱ ╲
╱────────╲ Property (some)
╱ ╲ Invariants, edge cases
╱────────────╲ Integration (more)
╱ ╲ Component boundaries
╱────────────────╲ Unit (many)
Individual functions
```
## Test Organization
```
tests/
├── unit/
│ ├── test_<module>.{ext}
│ └── ...
├── integration/
│ ├── test_<component>_<integration>.{ext}
│ └── ...
├── property/
│ ├── test_<invariant>.{ext}
│ └── ...
├── e2e/
│ ├── test_<journey>.{ext}
│ └── ...
├── fixtures/ # Shared test data
│ ├── valid_inputs.json
│ └── ...
└── conftest.{ext} # Shared setup (pytest) or similar
```
## Framework Selection by Language
| Language | Unit | Property | Integration | E2E |
|----------|------|----------|-------------|-----|
| Rust | `#[test]`, cargo test | proptest, quickcheck | tokio::test | - |
| TypeScript | Jest, Vitest | fast-check | Supertest | Playwright |
| Python | pytest | Hypothesis | pytest + fixtures | Playwright |
| Go | testing | gopter | testcontainers | - |
| Zig | std.testing | - | - | - |
## Coverage Requirements
| Level | Minimum Coverage | Measured By |
|-------|------------------|-------------|
| Spec | 100% normative paragraphs | Trace marker presence |
| Unit | 80% line coverage | Coverage tools |
| Integration | Critical paths | Manual review |
| E2E | Happy paths | Journey checklist |
## Quick Reference
1. **Before coding**: Write failing test with `@trace SPEC-XX.YY`
2. **Test naming**: `test_<what>_<scenario>_<expected>`
3. **One focus**: Each test verifies one thing
4. **Fast feedback**: Unit tests run in <1s total
5. **Isolation**: Unit tests mock externals
6. **Coverage**: Every spec paragraph has a test
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.