testing
Testing Best Practices
Core Philosophy
Write invariant-based tests that verify what SHOULD be true, not bug-affirming tests that prove bugs existed.
Test-Driven Development (TDD)
ALWAYS use TDD when fixing bugs:
- Find existing tests for the broken functionality
- Run them to verify they pass (shouldn't catch bug)
- Improve tests until they fail (exposing the bug)
- Fix the code to make tests pass
- Verify all tests pass
Quick Start
# Look for existing fixtures in conftest.py
grep -r "@pytest.fixture" tests/conftest.py
# Look at sibling test files for patterns
ls tests/test_<module_name>/
# Run tests with coverage
pytest --cov=src --cov-report=term-missing
Critical Rules Quick Reference
Mocking
# ALWAYS use patch.object
@patch.object(MyClass, 'method_name')
# ALWAYS mock dependencies, NEVER the system under test
generator = NewsPostGenerator()
generator._queries_chain = AsyncMock() # Mock dependency
await generator.generate_news_post(...) # Test actual code
Test Data
# ALWAYS use Pydantic models
return UserResult(user_id=user_id, name="Test User", ...)
# NEVER use naked literals - extract constants
DEFAULT_TIMEOUT = 60
STALE_THRESHOLD = DEFAULT_TIMEOUT + 10
Invariant Testing
# Test what SHOULD be true
def test_selector_populated_with_all_names():
"""INVARIANT: Selector contains all names from config."""
config = make_config_with_items(["item1", "item2", "item3"])
page = setup_page_with_config(config)
assert page.item_selector.options == ["item1", "item2", "item3"]
E2E Testing
# Call actual production code
await service.process_request(request_input)
published_event = mock_queue.publish.call_args.kwargs["output"]
assert published_event.data is not None
Intent & Testability
# Extract pure functions from infrastructure code
def apply_suffix(user_id: str, name: str, is_special: bool) -> tuple[str, str]:
"""Pure function - easily testable without mocks."""
if is_special:
return f"{user_id}_special", f"{name}_special"
return user_id, name
# Test behavior (inputs -> outputs), not implementation
@pytest.mark.parametrize("user_id,name,is_special,expected_id,expected_name", [
("alice", "Alice", True, "alice_special", "Alice_special"),
("alice", "Alice", False, "alice", "Alice"),
])
def test_suffix_behavior(user_id, name, is_special, expected_id, expected_name):
result_id, result_name = apply_suffix(user_id, name, is_special)
assert result_id == expected_id
# NEVER write sham tests that mock __init__ and set internal state
# They test the mock setup, not production code
Testing Checklist
Before committing:
- All imports at top of file
- Using
patch.object, notpatch - No mocking of the system under test
- No mocking of model classes
- Test data uses Pydantic models
- Checked conftest.py for existing fixtures
- No naked literals - all values are constants
- Using correct fixture decorators
- Asserting invariants early
- Mock args accessed with
.args[N]/.kwargs["name"] - E2E tests call actual production code
- Tests verify invariants, not bug existence
- 100% coverage of new code
- All tests pass
Reference Files
For detailed patterns and examples:
- references/mocking.md - Mocking strategies and when to mock
- references/test-data.md - Test data creation patterns
- references/e2e-testing.md - E2E and user journey patterns
- references/intent-and-testability.md - Intent documentation, pure functions, testability
- references/concurrency.md - Concurrency testing patterns
- references/fixtures.md - Common fixtures and decorators
Remember: When user reports bug, use TDD - find tests -> run -> improve until fail -> fix code -> verify pass.
More from gigaverse-app/skillet
metaskill-authoring
Write Claude Code skills and SKILL.md files. Use when creating new skills, writing skill content, structuring SKILL.md, organizing skill directories, or when user mentions "write skill", "create skill", "author skill", "new skill", "skill structure", "SKILL.md", "skill content", "skill template".
9metaskill-triggering
Optimize skill triggers and descriptions for reliable activation. Use when skill is not triggering, optimizing trigger keywords, writing frontmatter, debugging activation, or when user mentions "trigger", "frontmatter", "description", "skill not triggering", "optimize trigger", "skill won't fire", "skill activation", "trigger keywords".
8metaskill-packaging
Package skills, agents, commands, and hooks as Claude Code plugins. Use when creating plugins, packaging skills for distribution, setting up plugin structure, dogfooding plugins, or when user mentions "plugin structure", "plugin.json", "package plugin", "distribute plugin", "marketplace", "dogfood", "install plugin", "plugin placement", "--plugin-dir".
8metaskill-naming
Brainstorm and validate names for plugins, skills, agents, and commands. Use when naming a new plugin, choosing atom names, validating naming conventions, or when user mentions "name plugin", "name skill", "naming convention", "brainstorm names", "what should I call", "plugin name", "good name for".
7metaskill-grouping
Create skill groups (multiple related skills packaged as a plugin). Use when creating plugins, organizing multiple related skills, building skill families, packaging tools together, or when user mentions "plugin", "multiple skills", "related skills", "skill group", "skill family", "organize skills", "cross-reference", "package skills", "shared agents". ALWAYS consider this pattern when someone asks to "create a skill" - they often need a skill GROUP packaged as a plugin.
7nicegui-development
Use when building UI with NiceGUI, creating components, fixing styling issues, or when user mentions "nicegui", "quasar", "tailwind", "ui.row", "ui.column", "gap spacing", "state management", "controller", "dialog", "modal", "ui component", "ui layout".
6