python-testing-heavyweight
SKILL.md
Python Testing (Heavyweight)
Overview
Same philosophy as lightweight testing, but with real infrastructure instead of monkey-patching. Containers, mock servers, custom mock binaries.
When to Use
- Project has external API dependencies
- Features depend on system services (DBus, specific binaries)
- Integration failures are costly to debug
- Lightweight testing can't cover the critical paths
Core Idea
| Instead of... | Use... |
|---|---|
@patch("requests.get") |
Real HTTP server |
@patch("subprocess.run") |
Custom mock binary |
Mock() for database |
Real DB in container |
| Monkeypatched file ops | Real filesystem in tmp_path |
| Mocked system services | Real daemon instance |
Key Patterns
- Containerized services:
docker-compose.test.ymlwith mock API, test DB - Mock binaries: real executables that mimic expected behavior
- Session-scoped fixtures: start containers once per test session
- Real DBus: start
dbus-daemon --sessionfor tests
Investment Decision
- Will the project live long enough to justify setup time?
- Are integration failures actually happening?
- Can lightweight testing cover 80% of the risk?
If not all three: stick with lightweight.
Reference
See guides/testing-heavyweight.md for container setup, mock binary examples, CI integration, and stateful mock servers.
Weekly Installs
1
Repository
quick-brown-fox…s_pythonFirst Seen
8 days ago
Security Audits
Installed on
amp1
cline1
opencode1
cursor1
kimi-cli1
codex1