| name | defining-minidyn-tdd |
| description | Apply a rigorous Test-Driven Development (TDD) workflow for the Minidyn project. Use when adding features, fixing bugs, changing behavior, refactoring, or when the user mentions TDD, use cases, or "test first". |
Defining Minidyn TDD
Purpose
Use this skill to apply a consistent TDD workflow in this repository:
- Clarify use cases first.
- Define test cases from those use cases.
- Write tests before implementing.
- Implement the minimum change to pass.
- Verify behavior and report coverage/risks.
If there is tension between speed and order, maintain the TDD order: tests first, then code.
Mandatory Workflow
Copy this checklist into your response and keep it updated:
TDD Progress:
- [ ] Step 1: Clarify use cases
- [ ] Step 2: Convert use cases to test cases
- [ ] Step 3: Write failing tests first (RED)
- [ ] Step 4: Implement minimum code (GREEN)
- [ ] Step 5: Safe refactor (REFACTOR)
- [ ] Step 6: Verify and report
Step 1: Clarify Use Cases
Before editing production code, define:
- Actor/context
- Input/trigger
- Expected output/effect
- Edge cases
- Error paths
Write these in short bullets. If there is ambiguity, ask clarifying questions before coding.
Step 2: Convert Use Cases to Test Cases
For each use case, define at least:
- A happy path test
- An edge case test
- A failure/error test (when applicable)
Map each use case to test names with a 1:1 relationship when possible. Use this template:
Use Case: <name>
- Given: <initial state>
- When: <action>
- Then: <expected result>
- Test File: <path>
- Test Name: <it/describe title>
Step 3: Write Failing Tests First (RED)
- Create or update tests before implementing.
- Run specific tests and confirm they fail for the expected reason.
- If it's a bugfix: first reproduce the bug with a failing test.
Evidence to capture in your response:
- Test command executed
- Names of failing tests
- Short reason for failure
Step 4: Implement Minimum Code (GREEN)
- Implement only what is necessary to pass the failing tests.
- Avoid unrelated refactors while moving from RED to GREEN.
- Keep changes small and local.
Step 5: Safe Refactor (REFACTOR)
Optional, only after GREEN:
- Improve readability
- Remove duplication
- Maintain behavior unchanged
- Run affected tests after every non-trivial refactor.
Step 6: Verify and Report
Always run:
- Specific tests for the changed area:
go test -v -run ^TestName$ ./path/to/package
- Full suite for regressions:
go test ./...
- Coverage check (Must pass):
bash scripts/check_coverage.sh
Report using this format:
Verification Report
- Use cases covered: <n>/<total>
- Tests added: <list>
- Tests updated: <list>
- Commands executed: <list>
- Result: <pass/fail + key details>
- Remaining risks: <bullets or "none identified">
Minidyn-Specific Considerations
- Interpreter Changes: If modifying
interpreter/language/evaluator.go or interpreter/language/functions.go, tests must be added to evaluator_test.go or functions_test.go.
- API Changes: If DynamoDB input shapes change, remember to regenerate the requests file:
go run ./tools/generate_requests.
- Debugging: Never touch non-test code until a failing reproducing test exists.
Output Contract
When using this skill, your response MUST include:
- Explicit use cases
- Explicit test plan tied to use cases (Given/When/Then)
- Confirmation that tests were written first (RED evidence)
- Verification results with executed commands (Coverage & Suite)
If any point is missing, explicitly mark it as a gap before closing.
