mcouthon/agents

Overview

This skill helps you design a practical behavioral testing strategy: decide what to test, which doubles to use, and how to avoid brittle tests. It focuses on writing tests that verify observable behavior through public APIs rather than internal implementation. Use it to improve test quality, guide refactors, and ensure tests catch real regressions.

How this skill works

I inspect your test plans and examples against a five-question self-test that ensures structure-independence and behavioral focus. I recommend the simplest test doubles using a decision tree (real → fake → stub → mock-at-boundary) and flag anti-patterns like over-mocking, mirror tests, and logic inside tests. I produce clear rules for what to test, naming, structure (Arrange-Act-Assert), and a final checklist to validate test quality.

When to use it

• You are writing new tests and want to ensure they catch real regressions
• Reviewing an existing test suite that is brittle or tightly coupled to implementation
• Fixing tests that assert call sequences or verify mocks instead of outcomes
• Defining which collaborators to fake, stub, or test with real implementations
• Preparing to refactor code and needing confidence tests will survive internal rewrites

Best practices

• Apply the five-question Self-Test to every test: behavior over structure
• Prefer real implementations; use fakes for slow or non-deterministic systems
• Mock only at external boundaries (HTTP, DB, filesystem, clock), not internal collaborators
• Write one test per observable behavior: Given X, When Y, Then Z
• Keep tests DAMP (clear and descriptive) not DRY; avoid logic inside tests
• Name tests with scenario + expected outcome and follow Arrange→Act→Assert

Example use cases

• Deciding whether to use an in-memory DB, a fake server, or stubs for integration tests
• Rewriting a test suite before a major refactor to ensure tests are structure-insensitive
• Converting over-mocked unit tests into behavior-driven integration-style tests
• Writing a failing regression test first to capture a bug, then fixing the bug
• Auditing a test suite with the provided quality checklist before committing