aigroup-workflow 2.2.0 → 2.2.2

package/skills/quality/tdd-guide/references/framework-guide.md

@@ -1,206 +1,206 @@
-# Testing Framework Guide
-
-Language and framework selection, configuration, and patterns.
-
----
-
-## Table of Contents
-
-- [Framework Selection](#framework-selection)
-- [TypeScript/JavaScript](#typescriptjavascript)
-- [Python](#python)
-- [Java](#java)
-- [Version Requirements](#version-requirements)
-
----
-
-## Framework Selection
-
-| Language | Recommended | Alternatives | Best For |
-|----------|-------------|--------------|----------|
-| TypeScript/JS | Jest | Vitest, Mocha | React, Node.js, Next.js |
-| Python | Pytest | unittest, nose2 | Django, Flask, FastAPI |
-| Java | JUnit 5 | TestNG | Spring, Android |
-| Vite projects | Vitest | Jest | Modern Vite-based apps |
-
----
-
-## TypeScript/JavaScript
-
-### Jest Configuration
-
-```javascript
-// jest.config.js
-module.exports = {
-  preset: 'ts-jest',
-  testEnvironment: 'node',
-  testMatch: ['**/*.test.ts'],
-  collectCoverageFrom: ['src/**/*.ts'],
-  coverageThreshold: {
-    global: { branches: 80, lines: 80 }
-  }
-};
-```
-
-### Jest Test Pattern
-
-```typescript
-describe('Calculator', () => {
-  let calc: Calculator;
-
-  beforeEach(() => {
-    calc = new Calculator();
-  });
-
-  it('should add two numbers', () => {
-    expect(calc.add(2, 3)).toBe(5);
-  });
-
-  it('should throw on invalid input', () => {
-    expect(() => calc.add(null, 3)).toThrow('Invalid input');
-  });
-});
-```
-
-### Vitest Configuration
-
-```typescript
-// vitest.config.ts
-import { defineConfig } from 'vitest/config';
-
-export default defineConfig({
-  test: {
-    globals: true,
-    environment: 'node',
-    coverage: { provider: 'c8' }
-  }
-});
-```
-
-### Coverage Tools
-- Istanbul/nyc: Traditional coverage
-- c8: Native V8 coverage (faster)
-- Vitest built-in: Integrated with test runner
-
----
-
-## Python
-
-### Pytest Configuration
-
-```ini
-# pytest.ini
-[pytest]
-testpaths = tests
-python_files = test_*.py
-python_functions = test_*
-addopts = --cov=src --cov-report=term-missing
-```
-
-### Pytest Test Pattern
-
-```python
-import pytest
-from calculator import Calculator
-
-class TestCalculator:
-    @pytest.fixture
-    def calc(self):
-        return Calculator()
-
-    def test_add_positive_numbers(self, calc):
-        assert calc.add(2, 3) == 5
-
-    def test_add_raises_on_invalid_input(self, calc):
-        with pytest.raises(ValueError, match="Invalid input"):
-            calc.add(None, 3)
-
-    @pytest.mark.parametrize("a,b,expected", [
-        (1, 2, 3),
-        (-1, 1, 0),
-        (0, 0, 0),
-    ])
-    def test_add_various_inputs(self, calc, a, b, expected):
-        assert calc.add(a, b) == expected
-```
-
-### Coverage Tools
-- coverage.py: Standard Python coverage
-- pytest-cov: Pytest plugin wrapper
-- Report formats: HTML, XML, LCOV
-
----
-
-## Java
-
-### JUnit 5 Configuration (Maven)
-
-```xml
-<!-- pom.xml -->
-<dependency>
-    <groupId>org.junit.jupiter</groupId>
-    <artifactId>junit-jupiter</artifactId>
-    <version>5.9.3</version>
-    <scope>test</scope>
-</dependency>
-<plugin>
-    <groupId>org.jacoco</groupId>
-    <artifactId>jacoco-maven-plugin</artifactId>
-    <version>0.8.10</version>
-</plugin>
-```
-
-### JUnit 5 Test Pattern
-
-```java
-import org.junit.jupiter.api.*;
-import static org.junit.jupiter.api.Assertions.*;
-
-class CalculatorTest {
-    private Calculator calc;
-
-    @BeforeEach
-    void setUp() {
-        calc = new Calculator();
-    }
-
-    @Test
-    @DisplayName("should add two positive numbers")
-    void testAddPositive() {
-        assertEquals(5, calc.add(2, 3));
-    }
-
-    @Test
-    @DisplayName("should throw on null input")
-    void testAddThrowsOnNull() {
-        assertThrows(IllegalArgumentException.class,
-            () -> calc.add(null, 3));
-    }
-
-    @ParameterizedTest
-    @CsvSource({"1,2,3", "-1,1,0", "0,0,0"})
-    void testAddVarious(int a, int b, int expected) {
-        assertEquals(expected, calc.add(a, b));
-    }
-}
-```
-
-### Coverage Tools
-- JaCoCo: Standard Java coverage
-- Cobertura: Alternative XML format
-- Report formats: HTML, XML, CSV
-
----
-
-## Version Requirements
-
-| Tool | Minimum Version | Notes |
-|------|-----------------|-------|
-| Node.js | 16+ | Required for Jest 29+ |
-| Jest | 29+ | Modern async support |
-| Vitest | 0.34+ | Stable API |
-| Python | 3.8+ | f-strings, async support |
-| Pytest | 7+ | Modern fixtures |
-| Java | 11+ | JUnit 5 support |
-| JUnit | 5.9+ | ParameterizedTest improvements |
-| TypeScript | 4.5+ | Strict mode features |
+# Testing Framework Guide
+
+Language and framework selection, configuration, and patterns.
+
+---
+
+## Table of Contents
+
+- [Framework Selection](#framework-selection)
+- [TypeScript/JavaScript](#typescriptjavascript)
+- [Python](#python)
+- [Java](#java)
+- [Version Requirements](#version-requirements)
+
+---
+
+## Framework Selection
+
+| Language | Recommended | Alternatives | Best For |
+|----------|-------------|--------------|----------|
+| TypeScript/JS | Jest | Vitest, Mocha | React, Node.js, Next.js |
+| Python | Pytest | unittest, nose2 | Django, Flask, FastAPI |
+| Java | JUnit 5 | TestNG | Spring, Android |
+| Vite projects | Vitest | Jest | Modern Vite-based apps |
+
+---
+
+## TypeScript/JavaScript
+
+### Jest Configuration
+
+```javascript
+// jest.config.js
+module.exports = {
+  preset: 'ts-jest',
+  testEnvironment: 'node',
+  testMatch: ['**/*.test.ts'],
+  collectCoverageFrom: ['src/**/*.ts'],
+  coverageThreshold: {
+    global: { branches: 80, lines: 80 }
+  }
+};
+```
+
+### Jest Test Pattern
+
+```typescript
+describe('Calculator', () => {
+  let calc: Calculator;
+
+  beforeEach(() => {
+    calc = new Calculator();
+  });
+
+  it('should add two numbers', () => {
+    expect(calc.add(2, 3)).toBe(5);
+  });
+
+  it('should throw on invalid input', () => {
+    expect(() => calc.add(null, 3)).toThrow('Invalid input');
+  });
+});
+```
+
+### Vitest Configuration
+
+```typescript
+// vitest.config.ts
+import { defineConfig } from 'vitest/config';
+
+export default defineConfig({
+  test: {
+    globals: true,
+    environment: 'node',
+    coverage: { provider: 'c8' }
+  }
+});
+```
+
+### Coverage Tools
+- Istanbul/nyc: Traditional coverage
+- c8: Native V8 coverage (faster)
+- Vitest built-in: Integrated with test runner
+
+---
+
+## Python
+
+### Pytest Configuration
+
+```ini
+# pytest.ini
+[pytest]
+testpaths = tests
+python_files = test_*.py
+python_functions = test_*
+addopts = --cov=src --cov-report=term-missing
+```
+
+### Pytest Test Pattern
+
+```python
+import pytest
+from calculator import Calculator
+
+class TestCalculator:
+    @pytest.fixture
+    def calc(self):
+        return Calculator()
+
+    def test_add_positive_numbers(self, calc):
+        assert calc.add(2, 3) == 5
+
+    def test_add_raises_on_invalid_input(self, calc):
+        with pytest.raises(ValueError, match="Invalid input"):
+            calc.add(None, 3)
+
+    @pytest.mark.parametrize("a,b,expected", [
+        (1, 2, 3),
+        (-1, 1, 0),
+        (0, 0, 0),
+    ])
+    def test_add_various_inputs(self, calc, a, b, expected):
+        assert calc.add(a, b) == expected
+```
+
+### Coverage Tools
+- coverage.py: Standard Python coverage
+- pytest-cov: Pytest plugin wrapper
+- Report formats: HTML, XML, LCOV
+
+---
+
+## Java
+
+### JUnit 5 Configuration (Maven)
+
+```xml
+<!-- pom.xml -->
+<dependency>
+    <groupId>org.junit.jupiter</groupId>
+    <artifactId>junit-jupiter</artifactId>
+    <version>5.9.3</version>
+    <scope>test</scope>
+</dependency>
+<plugin>
+    <groupId>org.jacoco</groupId>
+    <artifactId>jacoco-maven-plugin</artifactId>
+    <version>0.8.10</version>
+</plugin>
+```
+
+### JUnit 5 Test Pattern
+
+```java
+import org.junit.jupiter.api.*;
+import static org.junit.jupiter.api.Assertions.*;
+
+class CalculatorTest {
+    private Calculator calc;
+
+    @BeforeEach
+    void setUp() {
+        calc = new Calculator();
+    }
+
+    @Test
+    @DisplayName("should add two positive numbers")
+    void testAddPositive() {
+        assertEquals(5, calc.add(2, 3));
+    }
+
+    @Test
+    @DisplayName("should throw on null input")
+    void testAddThrowsOnNull() {
+        assertThrows(IllegalArgumentException.class,
+            () -> calc.add(null, 3));
+    }
+
+    @ParameterizedTest
+    @CsvSource({"1,2,3", "-1,1,0", "0,0,0"})
+    void testAddVarious(int a, int b, int expected) {
+        assertEquals(expected, calc.add(a, b));
+    }
+}
+```
+
+### Coverage Tools
+- JaCoCo: Standard Java coverage
+- Cobertura: Alternative XML format
+- Report formats: HTML, XML, CSV
+
+---
+
+## Version Requirements
+
+| Tool | Minimum Version | Notes |
+|------|-----------------|-------|
+| Node.js | 16+ | Required for Jest 29+ |
+| Jest | 29+ | Modern async support |
+| Vitest | 0.34+ | Stable API |
+| Python | 3.8+ | f-strings, async support |
+| Pytest | 7+ | Modern fixtures |
+| Java | 11+ | JUnit 5 support |
+| JUnit | 5.9+ | ParameterizedTest improvements |
+| TypeScript | 4.5+ | Strict mode features |

package/skills/quality/tdd-guide/references/tdd-best-practices.md

@@ -1,128 +1,128 @@
-# TDD Best Practices
-
-Guidelines for effective test-driven development workflows.
-
----
-
-## Table of Contents
-
-- [Red-Green-Refactor Cycle](#red-green-refactor-cycle)
-- [Test Generation Guidelines](#test-generation-guidelines)
-- [Test Quality Principles](#test-quality-principles)
-- [Coverage Goals](#coverage-goals)
-
----
-
-## Red-Green-Refactor Cycle
-
-### RED Phase
-1. Write a failing test before any implementation
-2. Test should fail for the right reason (not compilation errors)
-3. Name tests as specifications describing expected behavior
-4. Keep tests small and focused on single behaviors
-
-### GREEN Phase
-1. Write minimal code to make the test pass
-2. Avoid over-engineering at this stage
-3. Duplicate code is acceptable temporarily
-4. Focus on correctness, not elegance
-
-### REFACTOR Phase
-1. Improve code structure while keeping tests green
-2. Remove duplication introduced in GREEN phase
-3. Apply design patterns where appropriate
-4. Run tests after each small refactoring
-
-### Cycle Discipline
-- Complete one cycle before starting the next
-- Commit after each successful GREEN phase
-- Small iterations lead to better designs
-- Resist temptation to write implementation first
-
----
-
-## Test Generation Guidelines
-
-### Behavior Focus
-- Test what code does, not how it does it
-- Avoid coupling tests to implementation details
-- Tests should survive internal refactoring
-- Focus on observable outcomes
-
-### Naming Conventions
-- Use descriptive names that read as specifications
-- Format: `should_<expected>_when_<condition>`
-- Examples:
-  - `should_return_zero_when_cart_is_empty`
-  - `should_reject_negative_amounts`
-  - `should_apply_discount_for_members`
-
-### Test Structure
-- Follow Arrange-Act-Assert (AAA) pattern
-- Keep setup minimal and relevant
-- One logical assertion per test
-- Extract shared setup to fixtures
-
-### Coverage Scope
-- Happy path: Normal expected usage
-- Error cases: Invalid inputs, failures
-- Edge cases: Boundaries, empty states
-- Exceptional cases: Timeouts, nulls
-
----
-
-## Test Quality Principles
-
-### Independence
-- Each test runs in isolation
-- No shared mutable state between tests
-- Tests can run in any order
-- Parallel execution should work
-
-### Speed
-- Unit tests under 100ms each
-- Avoid I/O in unit tests
-- Mock external dependencies
-- Use in-memory databases for integration
-
-### Determinism
-- Same inputs produce same results
-- No dependency on system time or random values
-- Controlled test data
-- No flaky tests allowed
-
-### Clarity
-- Failure messages explain what went wrong
-- Test code is as clean as production code
-- Avoid clever tricks that obscure intent
-- Comments explain non-obvious setup
-
----
-
-## Coverage Goals
-
-### Thresholds by Type
-| Type | Target | Rationale |
-|------|--------|-----------|
-| Line coverage | 80%+ | Baseline for most projects |
-| Branch coverage | 70%+ | More meaningful than line |
-| Function coverage | 90%+ | Public APIs should be tested |
-
-### Critical Path Rules
-- Authentication: 100% coverage required
-- Payment processing: 100% coverage required
-- Data validation: 100% coverage required
-- Error handlers: Must test all paths
-
-### Avoiding Coverage Theater
-- High coverage != good tests
-- Focus on meaningful assertions
-- Test behaviors, not lines
-- Code review test quality, not just metrics
-
-### Coverage Analysis Workflow
-1. Generate coverage report after test run
-2. Identify uncovered critical paths (P0)
-3. Review medium-priority gaps (P1)
-4. Document accepted low-priority gaps (P2)
-5. Set threshold gates in CI pipeline
+# TDD Best Practices
+
+Guidelines for effective test-driven development workflows.
+
+---
+
+## Table of Contents
+
+- [Red-Green-Refactor Cycle](#red-green-refactor-cycle)
+- [Test Generation Guidelines](#test-generation-guidelines)
+- [Test Quality Principles](#test-quality-principles)
+- [Coverage Goals](#coverage-goals)
+
+---
+
+## Red-Green-Refactor Cycle
+
+### RED Phase
+1. Write a failing test before any implementation
+2. Test should fail for the right reason (not compilation errors)
+3. Name tests as specifications describing expected behavior
+4. Keep tests small and focused on single behaviors
+
+### GREEN Phase
+1. Write minimal code to make the test pass
+2. Avoid over-engineering at this stage
+3. Duplicate code is acceptable temporarily
+4. Focus on correctness, not elegance
+
+### REFACTOR Phase
+1. Improve code structure while keeping tests green
+2. Remove duplication introduced in GREEN phase
+3. Apply design patterns where appropriate
+4. Run tests after each small refactoring
+
+### Cycle Discipline
+- Complete one cycle before starting the next
+- Commit after each successful GREEN phase
+- Small iterations lead to better designs
+- Resist temptation to write implementation first
+
+---
+
+## Test Generation Guidelines
+
+### Behavior Focus
+- Test what code does, not how it does it
+- Avoid coupling tests to implementation details
+- Tests should survive internal refactoring
+- Focus on observable outcomes
+
+### Naming Conventions
+- Use descriptive names that read as specifications
+- Format: `should_<expected>_when_<condition>`
+- Examples:
+  - `should_return_zero_when_cart_is_empty`
+  - `should_reject_negative_amounts`
+  - `should_apply_discount_for_members`
+
+### Test Structure
+- Follow Arrange-Act-Assert (AAA) pattern
+- Keep setup minimal and relevant
+- One logical assertion per test
+- Extract shared setup to fixtures
+
+### Coverage Scope
+- Happy path: Normal expected usage
+- Error cases: Invalid inputs, failures
+- Edge cases: Boundaries, empty states
+- Exceptional cases: Timeouts, nulls
+
+---
+
+## Test Quality Principles
+
+### Independence
+- Each test runs in isolation
+- No shared mutable state between tests
+- Tests can run in any order
+- Parallel execution should work
+
+### Speed
+- Unit tests under 100ms each
+- Avoid I/O in unit tests
+- Mock external dependencies
+- Use in-memory databases for integration
+
+### Determinism
+- Same inputs produce same results
+- No dependency on system time or random values
+- Controlled test data
+- No flaky tests allowed
+
+### Clarity
+- Failure messages explain what went wrong
+- Test code is as clean as production code
+- Avoid clever tricks that obscure intent
+- Comments explain non-obvious setup
+
+---
+
+## Coverage Goals
+
+### Thresholds by Type
+| Type | Target | Rationale |
+|------|--------|-----------|
+| Line coverage | 80%+ | Baseline for most projects |
+| Branch coverage | 70%+ | More meaningful than line |
+| Function coverage | 90%+ | Public APIs should be tested |
+
+### Critical Path Rules
+- Authentication: 100% coverage required
+- Payment processing: 100% coverage required
+- Data validation: 100% coverage required
+- Error handlers: Must test all paths
+
+### Avoiding Coverage Theater
+- High coverage != good tests
+- Focus on meaningful assertions
+- Test behaviors, not lines
+- Code review test quality, not just metrics
+
+### Coverage Analysis Workflow
+1. Generate coverage report after test run
+2. Identify uncovered critical paths (P0)
+3. Review medium-priority gaps (P1)
+4. Document accepted low-priority gaps (P2)
+5. Set threshold gates in CI pipeline