tdd-pytest
Python/pytest TDD specialist for test-driven development workflows. Use when writing tests, auditing test quality, running pytest, or generating test reports. Integrates with uv and pyproject.toml configuration.
What this skill does
# TDD-Pytest Skill
Activate this skill when the user needs help with:
- Writing tests using TDD methodology (Red-Green-Refactor)
- Auditing existing pytest test files for quality
- Running tests with coverage
- Generating test reports to `TESTING_REPORT.local.md`
- Setting up pytest configuration in `pyproject.toml`
## TDD Workflow
### Red-Green-Refactor Cycle
1. **RED** - Write a failing test first
- Test should fail for the right reason (not import errors)
- Test should be minimal and focused
- Show the failing test output
2. **GREEN** - Write minimal code to pass
- Only implement what's needed to pass the test
- No premature optimization
- Show the passing test output
3. **REFACTOR** - Improve code while keeping tests green
- Clean up duplication
- Improve naming
- Extract functions/classes if needed
- Run tests after each change
## Test Organization
### File Structure
```text
project/
src/
module.py
tests/
conftest.py # Shared fixtures
test_module.py # Tests for module.py
pyproject.toml # Pytest configuration
```
### Naming Conventions
- Test files: `test_*.py` or `*_test.py`
- Test functions: `test_*`
- Test classes: `Test*`
- Fixtures: Descriptive names (`mock_database`, `sample_user`)
## Pytest Best Practices
### Fixtures
```python
import pytest
@pytest.fixture
def sample_config():
return {"key": "value"}
@pytest.fixture
def mock_client(mocker):
return mocker.MagicMock()
```
### Parametrization
```python
@pytest.mark.parametrize("input,expected", [
("hello", "HELLO"),
("world", "WORLD"),
("", ""),
])
def test_uppercase(input, expected):
assert input.upper() == expected
```
### Async Tests
```python
import pytest
@pytest.mark.asyncio
async def test_async_function():
result = await async_operation()
assert result == expected
```
### Exception Testing
```python
def test_raises_value_error():
with pytest.raises(ValueError, match="invalid input"):
process_input(None)
```
## Running Tests
### With uv
```bash
uv run pytest # Run all tests
uv run pytest tests/test_module.py # Run specific file
uv run pytest -k "test_name" # Run by name pattern
uv run pytest -v --tb=short # Verbose with short traceback
uv run pytest --cov=src --cov-report=term # With coverage
```
### Common Flags
- `-v` / `--verbose` - Detailed output
- `-x` / `--exitfirst` - Stop on first failure
- `--tb=short` - Short tracebacks
- `--tb=no` - No tracebacks
- `-k EXPR` - Run tests matching expression
- `-m MARKER` - Run tests with marker
- `--cov=PATH` - Coverage for path
- `--cov-report=term-missing` - Show missing lines
## pyproject.toml Configuration
### Minimal Setup
```toml
[tool.pytest.ini_options]
asyncio_mode = "auto"
testpaths = ["tests"]
```
### Full Configuration
```toml
[tool.pytest.ini_options]
asyncio_mode = "auto"
asyncio_default_fixture_loop_scope = "function"
testpaths = ["tests"]
python_files = ["test_*.py", "*_test.py"]
python_functions = ["test_*"]
python_classes = ["Test*"]
addopts = "-v --tb=short"
markers = [
"slow: marks tests as slow",
"integration: marks integration tests",
]
filterwarnings = [
"ignore::DeprecationWarning",
]
[tool.coverage.run]
source = ["src"]
branch = true
omit = ["tests/*", "*/__init__.py"]
[tool.coverage.report]
exclude_lines = [
"pragma: no cover",
"if TYPE_CHECKING:",
"raise NotImplementedError",
]
fail_under = 80
show_missing = true
```
## Report Generation
The `TESTING_REPORT.local.md` file should contain:
1. Test execution summary (passed/failed/skipped)
2. Coverage metrics by module
3. Audit findings by severity
4. Recommendations with file:line references
5. Evidence (command outputs)
## Integration with Conversation
When the user asks to write tests:
1. Check conversation history for context about what to test
2. Identify the code/feature being discussed
3. If unclear, ask clarifying questions:
- "What specific behavior should I test?"
- "Should I include edge cases for X?"
- "Do you want unit tests, integration tests, or both?"
4. Follow TDD: Write failing test first, then implement
## Commands Available
- `/tdd-pytest:init` - Initialize pytest configuration
- `/tdd-pytest:test [path]` - Write tests using TDD (context-aware)
- `/tdd-pytest:test-all` - Run all tests
- `/tdd-pytest:report` - Generate/update TESTING_REPORT.local.md
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.