Tdd
Drive implementation with red-green-refactor. Use when building features or fixing bugs test-first.
Install
$ agentstack add skill-cniska-skills-tdd ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-cniska-skills-tdd) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
TDD
Drive implementation through the red-green-refactor cycle.
Workflow
- Understand the behavior: read enough code to know what the change should do and where it belongs.
- Write one failing test: the test describes the next behavior to add. It must fail for the right reason.
- Make it pass: write the minimum code to pass the test. Nothing more.
- Refactor: clean up while green. Improve naming, remove duplication, simplify structure. Run tests after each change.
- Repeat: pick the next behavior and go back to step 2.
One test at a time. Each cycle is vertical — one test, one implementation, one refactor pass. Do not write multiple tests before implementing.
What to test
- Observable behavior through public interfaces.
- The contract the caller depends on, not the implementation behind it.
- Error paths that have meaningful recovery or user-facing consequences.
- Prefer DAMP (descriptive and meaningful phrases) over DRY in tests — each test should independently communicate what it verifies.
What not to test
- Implementation details that can change without affecting behavior.
- Type-system guarantees the compiler already enforces.
- Trivial pass-through or delegation with no logic.
Mock at boundaries
Mock at system boundaries (database, network, file system, external APIs), not between internal functions. Prefer real implementations when practical. If a test would survive a complete rewrite of the internals, it is testing the right thing.
See also
buildfor slice-by-slice executiontest-reviewfor review-time test adequacy checks
Red flags
- Writing all tests first, then all implementation (horizontal slicing)
- Mocking internals instead of testing through public interfaces
- Testing the shape of data instead of behavior
- Adding speculative tests for edge cases that cannot happen
- Refactoring while red
- Skipping the refactor step because tests pass
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: cniska
- Source: cniska/skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.