tdd

Name: tdd
Author: sordi-ai

17stars3forks

How to install tdd?

sordi-ai/skill-everything/tdd

$npx -y skills add sordi-ai/skill-everything --skill tdd

Installs into the current project.

Summary

Apply when adding new behavior or fixing a bug. Red-green-refactor cycle, test-first discipline, when TDD doesn't pay.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Test-Driven Development
2
3	Purpose: Prevents the common failure mode where agents write implementation first and tests second — producing tests that validate the code as-written rather than the intended behavior.
4
5	## Rules
6
7	### The Red-Green-Refactor Cycle
8
9	1. MUST: Always write a failing test before writing production code. The test defines the desired behavior. If you cannot articulate a failing test, you do not yet understand the requirement. Reference: ERR-2026-017.
10
11	2. MUST: Never write more production code than necessary to pass the current failing test. Resist the urge to implement the full feature. One test, one behavior, one pass. Then refactor.
12
13	3. SHOULD: After each green test, look for refactoring opportunities before writing the next test. Refactoring under green tests is safe. Refactoring without tests is gambling.
14
15	4. AVOID: Writing multiple tests at once before making any pass. One failing test at a time keeps feedback loops tight and prevents losing track of which behavior you are implementing.
16
17	### Test Design
18
19	5. SHOULD: Name tests to describe the scenario and expected outcome, not the function under test. `test_empty_cart_returns_zero_total` not `test_calculate_total`. The name is documentation.
20
21	6. MUST: Ensure each test is independent and can run in any order. Shared mutable state between tests causes flaky suites. Use setup/teardown or fresh fixtures per test.
22
23	7. SHOULD: Test behavior, not implementation. Assert on outputs and observable side effects, not internal method calls. Implementation-coupled tests break on every refactor.
24
25	8. AVOID: Testing private methods directly. Test through the public API. If a private method needs its own tests, it probably belongs in a separate module.
26
27	### Coverage and Boundaries
28
29	9. SHOULD: Cover the happy path, at least one edge case, and at least one error case per public function. Three tests minimum per meaningful behavior.
30
31	10. AVOID: Chasing 100% line coverage as a goal. Coverage measures execution, not correctness. A test that executes code without asserting anything is worthless. Aim for high branch coverage on business logic.
32
33	11. SHOULD: Use test doubles (mocks, stubs, fakes) only at architectural boundaries. Mock the database, the network, the file system — not your own classes. Over-mocking makes tests brittle and meaningless.
34
35	### When NOT to TDD
36
37	12. AVOID: TDD for exploratory prototypes and throwaway spikes. When you do not yet know what the interface should be, experimentation is more valuable than premature tests. Delete the spike afterward.
38
39	13. SHOULD: Use TDD for bug fixes — always. Write a test that reproduces the bug first. Green means the bug is fixed. This prevents regressions permanently.
40
41	14. AVOID: TDD for pure configuration, static markup, or generated code. If there is no branching logic, there is nothing meaningful to test-drive.
42
43	### Discipline
44
45	15. MUST: Never commit code where all tests pass but you skipped the red step. If you wrote production code first and tests second, those tests may not actually exercise the new behavior. Rewrite them.
46
47	## See also
48
49	- `skills/code-quality/SKILL.md` — General quality rules including testing conventions
50	- `skills/python/SKILL.md` — Python-specific pytest patterns (rules 16–23)
51
52	## Why This Sub-Skill Earns Stars
53
54	LLM agents almost universally write code first and tests second — or skip tests entirely. This produces tests that validate the implementation rather than the specification, meaning bugs in the implementation are "verified" by the test. The red-green-refactor discipline catches this: if you never saw the test fail, you cannot trust that it tests anything real.

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

tdd

17stars3forks

View on GitHub

How to install tdd?

sordi-ai/skill-everything/tdd

$npx -y skills add sordi-ai/skill-everything --skill tdd

Installs into the current project.

Summary

Apply when adding new behavior or fixing a bug. Red-green-refactor cycle, test-first discipline, when TDD doesn't pay.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Test-Driven Development
2
3	Purpose: Prevents the common failure mode where agents write implementation first and tests second — producing tests that validate the code as-written rather than the intended behavior.
4
5	## Rules
6
7	### The Red-Green-Refactor Cycle
8
9	1. MUST: Always write a failing test before writing production code. The test defines the desired behavior. If you cannot articulate a failing test, you do not yet understand the requirement. Reference: ERR-2026-017.
10
11	2. MUST: Never write more production code than necessary to pass the current failing test. Resist the urge to implement the full feature. One test, one behavior, one pass. Then refactor.
12
13	3. SHOULD: After each green test, look for refactoring opportunities before writing the next test. Refactoring under green tests is safe. Refactoring without tests is gambling.
14
15	4. AVOID: Writing multiple tests at once before making any pass. One failing test at a time keeps feedback loops tight and prevents losing track of which behavior you are implementing.
16
17	### Test Design
18
19	5. SHOULD: Name tests to describe the scenario and expected outcome, not the function under test. `test_empty_cart_returns_zero_total` not `test_calculate_total`. The name is documentation.
20
21	6. MUST: Ensure each test is independent and can run in any order. Shared mutable state between tests causes flaky suites. Use setup/teardown or fresh fixtures per test.
22
23	7. SHOULD: Test behavior, not implementation. Assert on outputs and observable side effects, not internal method calls. Implementation-coupled tests break on every refactor.
24
25	8. AVOID: Testing private methods directly. Test through the public API. If a private method needs its own tests, it probably belongs in a separate module.
26
27	### Coverage and Boundaries
28
29	9. SHOULD: Cover the happy path, at least one edge case, and at least one error case per public function. Three tests minimum per meaningful behavior.
30
31	10. AVOID: Chasing 100% line coverage as a goal. Coverage measures execution, not correctness. A test that executes code without asserting anything is worthless. Aim for high branch coverage on business logic.
32
33	11. SHOULD: Use test doubles (mocks, stubs, fakes) only at architectural boundaries. Mock the database, the network, the file system — not your own classes. Over-mocking makes tests brittle and meaningless.
34
35	### When NOT to TDD
36
37	12. AVOID: TDD for exploratory prototypes and throwaway spikes. When you do not yet know what the interface should be, experimentation is more valuable than premature tests. Delete the spike afterward.
38
39	13. SHOULD: Use TDD for bug fixes — always. Write a test that reproduces the bug first. Green means the bug is fixed. This prevents regressions permanently.
40
41	14. AVOID: TDD for pure configuration, static markup, or generated code. If there is no branching logic, there is nothing meaningful to test-drive.
42
43	### Discipline
44
45	15. MUST: Never commit code where all tests pass but you skipped the red step. If you wrote production code first and tests second, those tests may not actually exercise the new behavior. Rewrite them.
46
47	## See also
48
49	- `skills/code-quality/SKILL.md` — General quality rules including testing conventions
50	- `skills/python/SKILL.md` — Python-specific pytest patterns (rules 16–23)
51
52	## Why This Sub-Skill Earns Stars
53
54	LLM agents almost universally write code first and tests second — or skip tests entirely. This produces tests that validate the implementation rather than the specification, meaning bugs in the implementation are "verified" by the test. The red-green-refactor discipline catches this: if you never saw the test fail, you cannot trust that it tests anything real.

People who liked this also viewed

6 picks

Type