testing-python

name	testing-python
description	Writes tests following TDD (using pytest and Hypothesis) and BDD best practices. Use when writing unit tests, integration tests, or BDD scenarios.
compatibility	Designed for Claude Code
metadata	{"allowed-tools":"Read, Grep, Glob, Edit, Write, Bash","argument-hint":["test-scope or component-name"],"stability":"stable","content-hash":"sha256:7ec36cfc580c044cc46fd4fece46741526f9252b688e55b741223b2397d42064","last-verified-cc-version":"1.0.34"}

Python Testing

Target: $ARGUMENTS

Writes focused, behavior-driven tests following project testing strategy.

Quick Reference

TDD methodology (language-agnostic): See tdd-core plugin (testing-tdd skill)

Python-specific documentation: references/

• references/testing-strategy.md - Python tools (pytest, Hypothesis, inline-snapshot, pytest-bdd)
• references/tdd-best-practices.md - Python TDD examples (extends tdd-core)
• references/bdd-best-practices.md - BDD methodology with pytest-bdd

Quick Decision

TDD (default): Use pytest for known cases, Hypothesis for edge cases. Works at unit/integration/acceptance levels.

BDD (optional): Use Given-When-Then for stakeholder collaboration on acceptance criteria.

See references/testing-strategy.md for full methodology comparison.

TDD Essentials (Quick Reference)

Cycle: RED (failing test) → GREEN (minimal pass) → REFACTOR (clean up)

Structure: Arrange-Act-Assert (AAA)

def test_order_processor_calculates_total():
    # ARRANGE
    items = [Item(price=10.00, qty=2), Item(price=5.00, qty=1)]
    processor = OrderProcessor()

    # ACT
    total = processor.calculate_total(items)

    # ASSERT
    assert total == 25.00

Hypothesis Priorities (Edge Cases within TDD)

Priority	Area	Example
CRITICAL	Math formulas	Scores always in bounds
CRITICAL	Loop termination	Never hangs
HIGH	Input validation	Handles any text
HIGH	Serialization	Always valid JSON

What to Test (KISS/DRY/YAGNI)

High-Value: Business logic, integration points, edge cases, contracts

Avoid: Library behavior, trivial assertions, implementation details, default constants, stale fixture patches (see references/testing-strategy.md → "Patterns to Remove")

See references/testing-strategy.md → "Patterns to Remove" for full list.

Naming Convention

Format: test_{module}_{component}_{behavior}

test_user_service_creates_new_user()
test_order_processor_validates_items()

Execution

make test              # All tests
make test_rerun        # Rerun failed tests (fast iteration)
make validate          # Full pre-commit validation
pytest tests/ -v       # Verbose
pytest -k test_user_   # Filter by name

Quality Gates

• All tests pass (make test)
• TDD Red-Green-Refactor followed
• Arrange-Act-Assert structure used
• Naming convention followed
• Behavior-focused (not implementation)
• No library behavior tested
• Mocks for third-party types use spec=RealClass