一键导入
clean-tests
Use when writing, fixing, editing, or refactoring Python tests. Enforces Clean Code principles—fast tests, boundary coverage, one assert per test.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when writing, fixing, editing, or refactoring Python tests. Enforces Clean Code principles—fast tests, boundary coverage, one assert per test.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when fixing, editing, changing, debugging, or working with any Python code. Applies the Boy Scout Rule—always leave code cleaner than you found it. Orchestrates other clean code skills as needed.
Use when writing, fixing, editing, or reviewing Python comments and docstrings. Enforces Clean Code principles—no metadata, no redundancy, no commented-out code.
Use when writing, fixing, editing, or refactoring Python functions. Enforces Clean Code principles—maximum 3 arguments, single responsibility, no flag parameters.
Use when writing, fixing, editing, or reviewing Python code quality. Enforces Clean Code's core principles—DRY, single responsibility, clear intent, no magic numbers, proper abstractions.
Use when naming, renaming, or fixing names of variables, functions, classes, or modules in Python. Enforces Clean Code principles—descriptive names, appropriate length, no encodings.
Use when fixing, editing, changing, debugging, or working with any TypeScript code. Applies the Boy Scout Rule—always leave code cleaner than you found it. Orchestrates other clean code skills as needed.
| name | clean-tests |
| description | Use when writing, fixing, editing, or refactoring Python tests. Enforces Clean Code principles—fast tests, boundary coverage, one assert per test. |
| when_to_use | Also trigger on: slow or flaky tests, `@pytest.mark.skip` without a clear reason, tests that only cover the happy path, tests with multiple assertions about different concepts, missing boundary cases (empty input, off-by-one, page zero), or asks about "coverage gap", "edge case", "did we test". |
Test everything that could possibly break. Use coverage tools as a guide, not a goal.
# Bad - only tests happy path
def test_divide():
assert divide(10, 2) == 5
# Good - tests edge cases too
def test_divide_normal():
assert divide(10, 2) == 5
def test_divide_by_zero():
with pytest.raises(ZeroDivisionError):
divide(10, 0)
def test_divide_negative():
assert divide(-10, 2) == -5
Coverage tools report gaps in your testing strategy. Don't ignore them.
# Run with coverage
pytest --cov=myproject --cov-report=term-missing
# Aim for meaningful coverage, not 100%
Trivial tests document behavior and catch regressions. They're worth more than their cost.
# Worth having - documents expected behavior
def test_user_default_role():
user = User(name="Alice")
assert user.role == "member"
Don't use @pytest.mark.skip to hide problems. Either fix the test or delete it.
# Bad - hiding a problem
@pytest.mark.skip(reason="flaky, fix later")
def test_async_operation():
...
# Good - either fix it or document why it's skipped
@pytest.mark.skip(reason="Requires Redis, see CONTRIBUTING.md for setup")
def test_cache_invalidation():
...
Bugs congregate at boundaries. Test them explicitly.
def test_pagination_boundaries():
items = list(range(100))
# First page
assert paginate(items, page=1, size=10) == items[0:10]
# Last page
assert paginate(items, page=10, size=10) == items[90:100]
# Beyond last page
assert paginate(items, page=11, size=10) == []
# Page zero (invalid)
with pytest.raises(ValueError):
paginate(items, page=0, size=10)
# Empty list
assert paginate([], page=1, size=10) == []
When you find a bug, write tests for all similar cases. Bugs cluster.
# Found bug: off-by-one in date calculation
# Now test ALL date boundaries
def test_month_boundaries():
assert last_day_of_month(2024, 1) == 31 # January
assert last_day_of_month(2024, 2) == 29 # Leap year February
assert last_day_of_month(2023, 2) == 28 # Non-leap February
assert last_day_of_month(2024, 4) == 30 # 30-day month
assert last_day_of_month(2024, 12) == 31 # December
When tests fail, look for patterns. They often point to deeper issues.
# If all async tests fail intermittently,
# the problem isn't the tests—it's the async handling
Look at which code paths are untested. Often they reveal design problems.
# If you can't easily test a function, it probably does too much
# Refactor for testability
Slow tests don't get run. Keep unit tests under 100ms each.
# Bad - hits real database
def test_user_creation():
db = connect_to_database() # Slow!
user = db.create_user("Alice")
assert user.name == "Alice"
# Good - uses mock or in-memory
def test_user_creation():
db = InMemoryDatabase()
user = db.create_user("Alice")
assert user.name == "Alice"
# Bad - testing multiple things
def test_user():
user = User("Alice", "alice@example.com")
assert user.name == "Alice"
assert user.email == "alice@example.com"
assert user.is_valid()
user.activate()
assert user.is_active
# Good - one concept each
def test_user_stores_name():
user = User("Alice", "alice@example.com")
assert user.name == "Alice"
def test_user_stores_email():
user = User("Alice", "alice@example.com")
assert user.email == "alice@example.com"
def test_new_user_is_valid():
user = User("Alice", "alice@example.com")
assert user.is_valid()
def test_user_can_be_activated():
user = User("Alice", "alice@example.com")
user.activate()
assert user.is_active
| Rule | Principle |
|---|---|
| T1 | Test everything that could break |
| T2 | Use coverage tools |
| T3 | Don't skip trivial tests |
| T4 | Ignored test = ambiguity question |
| T5 | Test boundary conditions |
| T6 | Exhaustively test near bugs |
| T7 | Look for patterns in failures |
| T8 | Check coverage when debugging |
| T9 | Tests must be fast (<100ms) |