[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73EBG72D4VG0DBPKF14WMTP":3,"skill-same:01M73EBG72D4VG0DBPKF14WMTP":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M73EBG72D4VG0DBPKF14WMTP","test-driven-development",null,"Implements software using Test-Driven Development (TDD) methodology with red-green-refactor cycle. Use when: developing new features, fixing bugs with tests, or ensuring code reliability through test-first approach.","5throck\u002Fai-workspace-standards","5throck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10958964?v=4","01M73BFEH0V0VS483TW4JD49JW","01M73BFEJ5VQZJHJSFTVPAZGDM",25,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-develop\u002F.gemini\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: test-driven-development\ndescription: >\n  Implements software using Test-Driven Development (TDD) methodology with red-green-refactor\n  cycle. Use when: developing new features, fixing bugs with tests, or ensuring code\n  reliability through test-first approach.\nversion: 1.2.0\nscope: co-develop\nstatus: active\nowner: pm\nlast_reviewed: 2026-11-06\nprerequisites: none\nrelates_to:\n  - skill: code-review\n    type: follows\ngemini-parity: skip\nmetadata:\n  type: process\n  triggers:\n    - tdd\n    - test driven development\n    - test first\n    - write tests first\n    - red green refactor\n    - test coverage\n---\n\n## Context\n\nThis skill provides systematic Test-Driven Development (TDD) workflow, ensuring code quality and reliability through the red-green-refactor cycle. It emphasizes writing tests before implementation, leading to more maintainable, better-designed code.\n\n## When to Use\n\n**Feature Development**:\n- Trigger: \"Implement feature using TDD\" or \"Test-first development\"\n- Use Case: Building new functionality with test coverage from the start\n\n**Bug Fixing**:\n- Trigger: \"Fix bug with test\" or \"Add failing test for bug\"\n- Use Case: Ensuring bugs are fixed and don't regress\n\n**Code Refactoring**:\n- Trigger: \"Refactor with test safety net\" or \"Improve code design\"\n- Use Case: Improving code structure while maintaining functionality\n\n**Quality Assurance**:\n- Trigger: \"Ensure test coverage\" or \"Add test safety net\"\n- Use Case: Building confidence in code correctness and preventing regressions\n\n---\n\n## Execution Steps\n\n## Step 1: Red - Write a Failing Test\n\n**Purpose**: Start by defining what success looks like.\n\n**Test Writing Process**:\n1. **Understand Requirements**:\n   - What should the code do?\n   - What are the edge cases?\n   - What should happen with invalid input?\n\n2. **Write Test Specification**:\n   - Test name describes the behavior\n   - Arrange-Act-Assert (AAA) pattern\n   - Clear test setup and teardown\n   - Meaningful assertions\n\n3. **Run Test - Verify Failure**:\n   - Test should fail (Red)\n   - Failure message should be meaningful\n   - Confirms test is testing the right thing\n\n**Test Quality Checklist**:\n- [ ] Test describes behavior, not implementation\n- [ ] Test has clear setup and teardown\n- [ ] Assertions are specific and meaningful\n- [ ] Test covers edge cases\n- [ ] Test is independent and isolated\n\n**Example Test Structure**:\n```python\ndef test_calculator_adds_two_numbers():\n    # Arrange\n    calculator = Calculator()\n    \n    # Act\n    result = calculator.add(2, 3)\n    \n    # Assert\n    assert result == 5\n```\n\n---\n\n## Step 2: Green - Make Test Pass\n\n**Purpose**: Write minimal code to pass the test.\n\n**Implementation Strategy**:\n1. **Write Minimal Implementation**:\n   - Just enough code to pass the test\n   - Don't worry about perfect design yet\n   - Hard-code values if needed (refactor later)\n\n2. **Run Test - Verify Success**:\n   - Test should pass (Green)\n   - All assertions should succeed\n   - No new tests should break\n\n3. **Keep It Simple**:\n   - Avoid over-engineering\n   - Focus on passing the test\n   - Don't add extra features\n   - Defer optimization to refactor step\n\n**Green Phase Principles**:\n- Speed over perfection\n- Working code over elegant code\n- Passing tests over comprehensive design\n- Implementation over abstraction\n\n**Common Mistakes**:\n- ❌ Writing too much code at once\n- ❌ Implementing features not tested\n- ❌ Optimizing prematurely\n- ❌ Skipping the test run\n\n---\n\n## Step 3: Refactor - Improve Code\n\n**Purpose**: Clean up code while keeping tests green.\n\n**Refactoring Process**:\n1. **Run All Tests**:\n   - Ensure baseline: all tests pass\n   - Confirm test coverage is adequate\n   - Identify code smells and improvements\n\n2. **Apply Refactoring**:\n   - Remove duplication\n   - Improve names and structure\n   - Extract methods\u002Fclasses\n   - Simplify complex logic\n\n3. **Run Tests After Each Change**:\n   - Tests should still pass (Green)\n   - Behavior is unchanged\n   - Only implementation improves\n\n**Refactoring Checklist**:\n- [ ] Code is DRY (Don't Repeat Yourself)\n- [ ] Names are descriptive and clear\n- [ ] Methods\u002Ffunctions are focused\n- [ ] Classes have single responsibility\n- [ ] Code is easy to understand\n- [ ] No unnecessary complexity\n- [ ] Performance is adequate\n\n**Refactoring Techniques**:\n- Extract Method\n- Extract Class\n- Rename Variable\u002FMethod\n- Introduce Parameter Object\n- Replace Conditional with Polymorphism\n- Decompose Conditional\n\n**Safe Refactoring**:\n- Small, incremental changes\n- Run tests after each change\n- Keep commits atomic\n- Document refactoring rationale\n\n---\n\n## Step 4: Repeat the Cycle\n\n**Purpose**: Build comprehensive test coverage incrementally.\n\n**Iteration Strategy**:\n1. **Next Test Case**:\n   - Add another test for edge case\n   - Test for error conditions\n   - Test for boundary values\n\n2. **Build Up Behavior**:\n   - Start with simple case\n   - Add complexity gradually\n   - Ensure all tests pass\n   - Refactor as needed\n\n3. **Coverage Goals**:\n   - Unit tests for individual functions\n   - Integration tests for interactions\n   - Edge case coverage\n   - Error handling coverage\n\n**Test Pyramid**:\n```\n    E2E Tests (few)\n       \u002F\\\n      \u002F  \\\n     \u002F    \\\n    \u002F      \\\n   \u002F        \\\n  \u002F Integration \\\n \u002F   Tests     \\\n\u002F______________\\\nUnit Tests (many)\n```\n\n---\n\n## Step 5: Test Quality Standards\n\n**Purpose**: Ensure tests provide long-term value.\n\n**Good Test Characteristics**:\n1. **Readability**:\n   - Test name describes behavior\n   - Test tells a story\n   - Setup is clear and minimal\n   - Assertions are meaningful\n\n2. **Maintainability**:\n   - Tests are independent\n   - Tests are fast\n   - Tests are reliable\n   - Tests don't duplicate implementation\n\n3. **Usefulness**:\n   - Tests catch real bugs\n   - Tests document behavior\n   - Tests guide refactoring\n   - Tests prevent regressions\n\n**Test Organization**:\n- Group related tests\n- Use test fixtures for setup\n- Follow naming conventions\n- Separate unit\u002Fintegration\u002Fe2e tests\n\n**Anti-Patterns to Avoid**:\n- Testing implementation details\n- Brittle tests that break easily\n- Slow tests that discourage running\n- Tests that require specific environment setup\n- Tests that don't assert meaningful behavior\n\n---\n\n## Step 6: TDD Best Practices\n\n**Purpose**: Apply TDD effectively in real projects.\n\n**Starting TDD**:\n1. **Begin with Simple Cases**:\n   - Start with new features\n   - Practice with isolated code\n   - Build confidence gradually\n\n2. **Test First Mindset**:\n   - Think about behavior before implementation\n   - Design APIs from usage perspective\n   - Consider edge cases upfront\n\n3. **Keep Tests Fast**:\n   - Use test doubles (mocks, stubs)\n   - Avoid external dependencies\n   - Parallelize test execution\n   - Keep tests independent\n\n**Common Challenges**:\n- **\"How do I test X?\"**: Break down into smaller, testable pieces\n- **\"Tests take too long\"**: Use mocks and avoid slow operations\n- **\"Code is hard to test\"**: Refactor for better testability\n- **\"Too many tests to update\"**: Better design reduces test duplication\n\n**TDD in Legacy Code**:\n1. Add tests around existing code (characterization tests)\n2. Refactor in small steps with test safety net\n3. Gradually improve test coverage\n4. Use tests to guide refactoring\n\n---\n\n## Output Format\n\n**For Feature Development**:\n- Comprehensive test suite for new feature\n- Production code that passes all tests\n- Clean, maintainable implementation\n- Documentation of expected behavior\n\n**For Bug Fixes**:\n- Failing test that reproduces bug\n- Minimal fix that makes test pass\n- Confidence bug won't regress\n- Documentation of bug behavior\n\n**For Refactoring**:\n- Test suite that protects behavior\n- Improved code structure\n- Confirmed functionality preserved\n- Better maintainability\n\n---\n\n## Best Practices\n\n**TDD Discipline**:\n✅ **Do**:\n- Write test before implementation\n- Keep tests fast and independent\n- Run tests frequently\n- Refactor confidently with test safety net\n- Treat test failures as first priority\n\n❌ **Don't**:\n- Write tests after code\n- Let tests slow you down (keep them fast)\n- Skip tests when \"in a hurry\"\n- Comment out failing tests\n- Make tests dependent on each other\n\n**Test Quality**:\n✅ **Do**:\n- Test behavior, not implementation\n- Use descriptive test names\n- Keep tests simple and focused\n- Update tests when requirements change\n- Treat tests as documentation\n\n❌ **Don't**:\n- Test implementation details\n- Use vague test names\n- Write complex tests\n- Let tests become outdated\n- Duplicate implementation in tests\n\n---\n\n## Common Mistakes to Avoid\n\n**TDD Anti-Patterns**:\n1. **Fake TDD**: Writing tests after code (\"green-red-refactor\")\n2. **Test-Induced Design**: Over-engineering for testability\n3. **Coverage Obsession**: Focusing on metrics over value\n4. **Testing Trivia**: Testing getters\u002Fsetters or simple methods\n5. **Fragile Tests**: Tests that break with implementation changes\n\n**Process Anti-Patterns**:\n1. **Skipping Red**: Not verifying test fails first\n2. **Skipping Refactor**: Leaving code messy after green\n3. **Big Steps**: Writing too much code between tests\n4. **Test Dependencies**: Tests that require specific order\n5. **Slow Tests**: Tests that discourage frequent running\n\n---\n\n## Spoke Derivation Note\n\nThis file is the hub-doctrine canonical for the co-develop generic dev spine\n(spec 2026-11-01-hub-consolidation-design, Phase 1 batch D). Co-develop\npipelines run it as written. A spoke variant derives from this doctrine by\nsubstituting the bindings below — the derivation never edits the\nsingle-valued frontmatter doctrine: `scope: co-develop` stays as written\nhere, and the spoke label lives in this note only.\n\nNo {{PROJECT_*}} placeholder is needed in this skill: its per-spoke deltas\nare frontmatter labels, not body prose, so they are documented as bindings\nrather than parameterized.\n\n| Spoke | Derivation binding |\n|---|---|\n| co-game | Ships byte-identical to co-develop, including `scope: co-develop` (merge ruling 2026-11-06, DEC-20261106-03: diverged same-version copies are merged, not split by version bump); no per-spoke scope rendering. |\n| co-learning | Not adopted — absent from Projects\u002Fco-learning and its template. The fleet skill-graph projection carries only a dangling reference node for it (content_hash null); it is not an installed consumer. |\n| co-abap | Not adopted — co-abap carries no TDD capability; its SAP quality chain (RunUnitTests\u002FATC via the test-runner agent) is a domain-specific workflow outside this generic spine. |\n\n---\n\n## Related Skills\n\n- **code-review**: For evaluating test quality and coverage\n- **refactoring**: For improving code design with test safety net\n- **testing-qa**: For comprehensive testing strategy beyond TDD\n- **continuous-integration**: For automating test runs in CI\u002FCD\n\n---\n\n## TDD Tools and Frameworks\n\n**Popular Testing Frameworks**:\n- **JavaScript**: Jest, Mocha, Jasmine, Vitest\n- **Python**: pytest, unittest, nose2\n- **Java**: JUnit, TestNG\n- **C#**: NUnit, xUnit\n- **Ruby**: RSpec, Minitest\n\n**Test Doubles Libraries**:\n- **JavaScript**: sinon.js, testdouble.js, jest.fn()\n- **Python**: unittest.mock, pytest-mock\n- **Java**: Mockito, PowerMock\n- **C#**: Moq, NSubstitute\n\n**Coverage Tools**:\n- **JavaScript**: Istanbul, nyc, c8\n- **Python**: pytest-cov, coverage.py\n- **Java**: JaCoCo, Cobertura\n- **General**: sonar-scanner, Codecov\n\n---\n\n## Testing Strategies\n\n**Unit Testing**:\n- Test individual functions\u002Fmethods in isolation\n- Use test doubles for external dependencies\n- Focus on business logic and algorithms\n- Keep tests fast and simple\n\n**Integration Testing**:\n- Test interactions between components\n- Use real dependencies (or realistic fakes)\n- Test database operations, API calls\n- Ensure components work together\n\n**E2E Testing**:\n- Test complete user workflows\n- Use real browser\u002Fenvironment\n- Test critical user paths\n- Keep E2E tests minimal (slow, brittle)\n\n**Property-Based Testing**:\n- Generate random test inputs\n- Verify invariants hold true\n- Find edge cases human testing misses\n- Tools: QuickCheck, Hypothesis, fast-check\n","## Context\n\nThis skill provides systematic Test-Driven Development (TDD) workflow, ensuring code quality and reliability through the red-green-refactor cycle. It emphasizes writing tests before implementation, leading to more maintainable, better-designed code.\n\n## When to Use\n\n**Feature Development**:\n- Trigger: \"Implement feature using TDD\" or \"Test-first development\"\n- Use Case: Building new functionality with test coverage from the start\n\n**Bug Fixing**:\n- Trigger: \"Fix bug with test\" or \"Add failing test for bug\"\n- Use Case: Ensuring bugs are fixed and don't regress\n\n**Code Refactoring**:\n- Trigger: \"Refactor with test safety net\" or \"Improve code design\"\n- Use Case: Improving code structure while maintaining functionality\n\n**Quality Assurance**:\n- Trigger: \"Ensure test coverage\" or \"Add test safety net\"\n- Use Case: Building confidence in code correctness and preventing regressions\n\n---\n\n## Execution Steps\n\n## Step 1: Red - Write a Failing Test\n\n**Purpose**: Start by defining what success looks like.\n\n**Test Writing Process**:\n1. **Understand Requirements**:\n   - What should the code do?\n   - What are the edge cases?\n   - What should happen with invalid input?\n\n2. **Write Test Specification**:\n   - Test name describes the behavior\n   - Arrange-Act-Assert (AAA) pattern\n   - Clear test setup and teardown\n   - Meaningful assertions\n\n3. **Run Test - Verify Failure**:\n   - Test should fail (Red)\n   - Failure message should be meaningful\n   - Confirms test is testing the right thing\n\n**Test Quality Checklist**:\n- [ ] Test describes behavior, not implementation\n- [ ] Test has clear setup and teardown\n- [ ] Assertions are specific and meaningful\n- [ ] Test covers edge cases\n- [ ] Test is independent and isolated\n\n**Example Test Structure**:\n```python\ndef test_calculator_adds_two_numbers():\n    # Arrange\n    calculator = Calculator()\n    \n    # Act\n    result = calculator.add(2, 3)\n    \n    # Assert\n    assert result == 5\n```\n\n---\n\n## Step 2: Green - Make Test Pass\n\n**Purpose**: Write minimal code to pass the test.\n\n**Implementation Strategy**:\n1. **Write Minimal Implementation**:\n   - Just enough code to pass the test\n   - Don't worry about perfect design yet\n   - Hard-code values if needed (refactor later)\n\n2. **Run Test - Verify Success**:\n   - Test should pass (Green)\n   - All assertions should succeed\n   - No new tests should break\n\n3. **Keep It Simple**:\n   - Avoid over-engineering\n   - Focus on passing the test\n   - Don't add extra features\n   - Defer optimization to refactor step\n\n**Green Phase Principles**:\n- Speed over perfection\n- Working code over elegant code\n- Passing tests over comprehensive design\n- Implementation over abstraction\n\n**Common Mistakes**:\n- ❌ Writing too much code at once\n- ❌ Implementing features not tested\n- ❌ Optimizing prematurely\n- ❌ Skipping the test run\n\n---\n\n## Step 3: Refactor - Improve Code\n\n**Purpose**: Clean up code while keeping tests green.\n\n**Refactoring Process**:\n1. **Run All Tests**:\n   - Ensure baseline: all tests pass\n   - Confirm test coverage is adequate\n   - Identify code smells and improvements\n\n2. **Apply Refactoring**:\n   - Remove duplication\n   - Improve names and structure\n   - Extract methods\u002Fclasses\n   - Simplify complex logic\n\n3. **Run Tests After Each Change**:\n   - Tests should still pass (Green)\n   - Behavior is unchanged\n   - Only implementation improves\n\n**Refactoring Checklist**:\n- [ ] Code is DRY (Don't Repeat Yourself)\n- [ ] Names are descriptive and clear\n- [ ] Methods\u002Ffunctions are focused\n- [ ] Classes have single responsibility\n- [ ] Code is easy to understand\n- [ ] No unnecessary complexity\n- [ ] Performance is adequate\n\n**Refactoring Techniques**:\n- Extract Method\n- Extract Class\n- Rename Variable\u002FMethod\n- Introduce Parameter Object\n- Replace Conditional with Polymorphism\n- Decompose Conditional\n\n**Safe Refactoring**:\n- Small, incremental changes\n- Run tests after each change\n- Keep commits atomic\n- Document refactoring rationale\n\n---\n\n## Step 4: Repeat the Cycle\n\n**Purpose**: Build comprehensive test coverage incrementally.\n\n**Iteration Strategy**:\n1. **Next Test Case**:\n   - Add another test for edge case\n   - Test for error conditions\n   - Test for boundary values\n\n2. **Build Up Behavior**:\n   - Start with simple case\n   - Add complexity gradually\n   - Ensure all tests pass\n   - Refactor as needed\n\n3. **Coverage Goals**:\n   - Unit tests for individual functions\n   - Integration tests for interactions\n   - Edge case coverage\n   - Error handling coverage\n\n**Test Pyramid**:\n```\n    E2E Tests (few)\n       \u002F\\\n      \u002F  \\\n     \u002F    \\\n    \u002F      \\\n   \u002F        \\\n  \u002F Integration \\\n \u002F   Tests     \\\n\u002F______________\\\nUnit Tests (many)\n```\n\n---\n\n## Step 5: Test Quality Standards\n\n**Purpose**: Ensure tests provide long-term value.\n\n**Good Test Characteristics**:\n1. **Readability**:\n   - Test name describes behavior\n   - Test tells a story\n   - Setup is clear and minimal\n   - Assertions are meaningful\n\n2. **Maintainability**:\n   - Tests are independent\n   - Tests are fast\n   - Tests are reliable\n   - Tests don't duplicate implementation\n\n3. **Usefulness**:\n   - Tests catch real bugs\n   - Tests document behavior\n   - Tests guide refactoring\n   - Tests prevent regressions\n\n**Test Organization**:\n- Group related tests\n- Use test fixtures for setup\n- Follow naming conventions\n- Separate unit\u002Fintegration\u002Fe2e tests\n\n**Anti-Patterns to Avoid**:\n- Testing implementation details\n- Brittle tests that break easily\n- Slow tests that discourage running\n- Tests that require specific environment setup\n- Tests that don't assert meaningful behavior\n\n---\n\n## Step 6: TDD Best Practices\n\n**Purpose**: Apply TDD effectively in real projects.\n\n**Starting TDD**:\n1. **Begin with Simple Cases**:\n   - Start with new features\n   - Practice with isolated code\n   - Build confidence gradually\n\n2. **Test First Mindset**:\n   - Think about behavior before implementation\n   - Design APIs from usage perspective\n   - Consider edge cases upfront\n\n3. **Keep Tests Fast**:\n   - Use test doubles (mocks, stubs)\n   - Avoid external dependencies\n   - Parallelize test execution\n   - Keep tests independent\n\n**Common Challenges**:\n- **\"How do I test X?\"**: Break down into smaller, testable pieces\n- **\"Tests take too long\"**: Use mocks and avoid slow operations\n- **\"Code is hard to test\"**: Refactor for better testability\n- **\"Too many tests to update\"**: Better design reduces test duplication\n\n**TDD in Legacy Code**:\n1. Add tests around existing code (characterization tests)\n2. Refactor in small steps with test safety net\n3. Gradually improve test coverage\n4. Use tests to guide refactoring\n\n---\n\n## Output Format\n\n**For Feature Development**:\n- Comprehensive test suite for new feature\n- Production code that passes all tests\n- Clean, maintainable implementation\n- Documentation of expected behavior\n\n**For Bug Fixes**:\n- Failing test that reproduces bug\n- Minimal fix that makes test pass\n- Confidence bug won't regress\n- Documentation of bug behavior\n\n**For Refactoring**:\n- Test suite that protects behavior\n- Improved code structure\n- Confirmed functionality preserved\n- Better maintainability\n\n---\n\n## Best Practices\n\n**TDD Discipline**:\n✅ **Do**:\n- Write test before implementation\n- Keep tests fast and independent\n- Run tests frequently\n- Refactor confidently with test safety net\n- Treat test failures as first priority\n\n❌ **Don't**:\n- Write tests after code\n- Let tests slow you down (keep them fast)\n- Skip tests when \"in a hurry\"\n- Comment out failing tests\n- Make tests dependent on each other\n\n**Test Quality**:\n✅ **Do**:\n- Test behavior, not implementation\n- Use descriptive test names\n- Keep tests simple and focused\n- Update tests when requirements change\n- Treat tests as documentation\n\n❌ **Don't**:\n- Test implementation details\n- Use vague test names\n- Write complex tests\n- Let tests become outdated\n- Duplicate implementation in tests\n\n---\n\n## Common Mistakes to Avoid\n\n**TDD Anti-Patterns**:\n1. **Fake TDD**: Writing tests after code (\"green-red-refactor\")\n2. **Test-Induced Design**: Over-engineering for testability\n3. **Coverage Obsession**: Focusing on metrics over value\n4. **Testing Trivia**: Testing getters\u002Fsetters or simple methods\n5. **Fragile Tests**: Tests that break with implementation changes\n\n**Process Anti-Patterns**:\n1. **Skipping Red**: Not verifying test fails first\n2. **Skipping Refactor**: Leaving code messy after green\n3. **Big Steps**: Writing too much code between tests\n4. **Test Dependencies**: Tests that require specific order\n5. **Slow Tests**: Tests that discourage frequent running\n\n---\n\n## Spoke Derivation Note\n\nThis file is the hub-doctrine canonical for the co-develop generic dev spine\n(spec 2026-11-01-hub-consolidation-design, Phase 1 batch D). Co-develop\npipelines run it as written. A spoke variant derives from this doctrine by\nsubstituting the bindings below — the derivation never edits the\nsingle-valued frontmatter doctrine: `scope: co-develop` stays as written\nhere, and the spoke label lives in this note only.\n\nNo {{PROJECT_*}} placeholder is needed in this skill: its per-spoke deltas\nare frontmatter labels, not body prose, so they are documented as bindings\nrather than parameterized.\n\n| Spoke | Derivation binding |\n|---|---|\n| co-game | Ships byte-identical to co-develop, including `scope: co-develop` (merge ruling 2026-11-06, DEC-20261106-03: diverged same-version copies are merged, not split by version bump); no per-spoke scope rendering. |\n| co-learning | Not adopted — absent from Projects\u002Fco-learning and its template. The fleet skill-graph projection carries only a dangling reference node for it (content_hash null); it is not an installed consumer. |\n| co-abap | Not adopted — co-abap carries no TDD capability; its SAP quality chain (RunUnitTests\u002FATC via the test-runner agent) is a domain-specific workflow outside this generic spine. |\n\n---\n\n## Related Skills\n\n- **code-review**: For evaluating test quality and coverage\n- **refactoring**: For improving code design with test safety net\n- **testing-qa**: For comprehensive testing strategy beyond TDD\n- **continuous-integration**: For automating test runs in CI\u002FCD\n\n---\n\n## TDD Tools and Frameworks\n\n**Popular Testing Frameworks**:\n- **JavaScript**: Jest, Mocha, Jasmine, Vitest\n- **Python**: pytest, unittest, nose2\n- **Java**: JUnit, TestNG\n- **C#**: NUnit, xUnit\n- **Ruby**: RSpec, Minitest\n\n**Test Doubles Libraries**:\n- **JavaScript**: sinon.js, testdouble.js, jest.fn()\n- **Python**: unittest.mock, pytest-mock\n- **Java**: Mockito, PowerMock\n- **C#**: Moq, NSubstitute\n\n**Coverage Tools**:\n- **JavaScript**: Istanbul, nyc, c8\n- **Python**: pytest-cov, coverage.py\n- **Java**: JaCoCo, Cobertura\n- **General**: sonar-scanner, Codecov\n\n---\n\n## Testing Strategies\n\n**Unit Testing**:\n- Test individual functions\u002Fmethods in isolation\n- Use test doubles for external dependencies\n- Focus on business logic and algorithms\n- Keep tests fast and simple\n\n**Integration Testing**:\n- Test interactions between components\n- Use real dependencies (or realistic fakes)\n- Test database operations, API calls\n- Ensure components work together\n\n**E2E Testing**:\n- Test complete user workflows\n- Use real browser\u002Fenvironment\n- Test critical user paths\n- Keep E2E tests minimal (slow, brittle)\n\n**Property-Based Testing**:\n- Generate random test inputs\n- Verify invariants hold true\n- Find edge cases human testing misses\n- Tools: QuickCheck, Hypothesis, fast-check\n",{"name":5,"owner":23,"scope":24,"status":25,"version":26,"metadata":27,"relates_to":36,"description":40,"gemini-parity":41,"last_reviewed":42,"prerequisites":43},"pm","co-develop","active","1.2.0",{"type":28,"triggers":29},"process",[30,31,32,33,34,35],"tdd","test driven development","test first","write tests first","red green refactor","test coverage",[37],{"type":38,"skill":39},"follows","code-review","Implements software using Test-Driven Development (TDD) methodology with red-green-refactor cycle. Use when: developing new features, fixing bugs with tests, or ensuring code reliability through test-first approach.\n","skip",1793923200000,"none","main","1162ccc568cf90c01b3886d6143cbfd851a37883","templates\u002Fco-develop\u002F.gemini\u002Fskills\u002Ftest-driven-development",9,"https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards","https:\u002F\u002Fgithub.com\u002F5throck","Experienced in digital transformation, enterprise IT, startup acceleration, and business strategy. Focused on building practical systems that connect technolo","2026-11-14 21:22:34",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add 5throck\u002Fai-workspace-standards --skill test-driven-development",{"tool":58,"command":59},"bunx","bunx skills add 5throck\u002Fai-workspace-standards --skill test-driven-development",{"tool":61,"command":62},"pnpm","pnpm dlx skills add 5throck\u002Fai-workspace-standards --skill test-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-develop\u002F.gemini\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",true,[],[67,73,79,85,92,99],{"skillNo":68,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":18},"01M73HG1JK5J3A3AMG6WNH8V6E","discovery","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Ftemplates\u002Fco-fixt\u002Fskills\u002Fdiscovery\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":18},"01M73HG0VZMCNH9YJX8ERV6R7C","x","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Ftemplates\u002Fco-bad\u002Fskills\u002Fx\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":18},"01M73HFZR1J6DMW5BRXG1ND6ET","root-skill","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Fskills\u002Froot-skill\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":18},"01M73HFSYWV2FPF895DK295NCV","update-bun-packages","Scans, updates, and upgrades Bun dependencies and packages across the AI workspace (L0) or standalone project (L2\u002FL3) while ensuring lockfile consistency, package.json version bumps, and security compliance. Use when: updating bun dependencies, upgrading packages to @latest, checking outdated packages in workspace or templates.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Fupdate-bun-packages\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":18},"01M73HFPZ7G1AHF80CDEJ94SZ9","ui-ux-design-intelligence","Provides comprehensive UI\u002FUX design capabilities including design system creation, component design, visual hierarchy, and user-centered design principles. Use when: building design systems, creating visual designs, designing UI components, or establishing design specifications.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Fui-ux-design-intelligence\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":18},"01M73HFMBER8AQEX2HF02JE2G4","translate","Translation helper for README and documentation files with diff preview and guidance","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Ftranslate\u002FSKILL.md",[],[]]