testing-guidelines
Testing Guidelines
Follow these principles when writing tests for this codebase.
Core Principles
1. Mock External Services, Use Real Fixtures
ALWAYS mock third-party network services. ALWAYS use fixtures based on real-world data.
- Fixtures must be scrubbed of PII (use dummy data like
foo@example.com,user-123) - Capture real API responses, then sanitize them
- Never make actual network calls in tests
2. Prefer Integration Tests Over Unit Tests
Focus on end-to-end style tests that validate inputs and outputs, not implementation details.
- Test the public interface, not internal methods
More from getsentry/warden
architecture-review
Staff-level codebase health review. Finds monolithic modules, silent failures, type safety gaps, test coverage holes, and LLM-friendliness issues.
138warden
Run Warden to analyze code changes before committing. Use when asked to "run warden", "check my changes", "review before commit", "warden config", "warden.toml", "create a warden skill", "add trigger", or any Warden-related local development task.
113agent-prompt
Reference guide for writing effective agent prompts and skills. Use when creating new skills, reviewing prompt quality, or understanding Warden's prompt architecture.
96warden-sweep
Full-repository code sweep. Scans every file with Warden, verifies findings through deep tracing, creates draft PRs for validated issues. Use when asked to "sweep the repo", "scan everything", "find all bugs", "full codebase review", "batch code analysis", or run Warden across the entire repository.
83find-warden-bugs
Warden-specific bug detection from historical patterns. Targets the architectural seams where bugs have repeatedly occurred: SDK IPC, dual report paths, config threading, concurrent execution, and output rendering.
68notseer
High-precision bug detection. Every report is a proof, not a suspicion. Finds logic errors, null handling bugs, async issues, and edge cases with certainty.
16