@nockdev/awf 6.2.0 → 6.2.2

package/.agent/skills/cross-cutting/tdd-workflow/META.yaml

@@ -0,0 +1,58 @@
+name: tdd-workflow
+version: "6.2.2"
+display: Test-Driven Development
+category: cross-cutting
+tier: 1
+priority: 1
+
+desc: "TDD methodology: Red-Green-Refactor, BDD, ATDD, property-based testing. Coverage strategies, test doubles, mutation testing. 12 languages, 180+ patterns."
+
+triggers:
+  file_patterns:
+    - "*.test.*"
+    - "*.spec.*"
+    - "*_test.*"
+    - "test_*.*"
+  keywords:
+    - tdd
+    - test-driven
+    - red-green-refactor
+    - bdd
+    - atdd
+    - failing test
+    - test first
+    - coverage
+    - mutation testing
+    - test double
+    - mock
+    - stub
+    - spy
+    - fixture
+    - property-based
+  intents:
+    - test-driven development
+    - write tests first
+    - TDD workflow
+    - coverage strategy
+
+caps:
+  - Red-Green-Refactor cycle
+  - BDD (Behavior-Driven Development)
+  - ATDD (Acceptance Test-Driven Development)
+  - Property-based testing
+  - Test doubles (mock, stub, spy, fake, dummy)
+  - Mutation testing
+  - Coverage strategies
+  - Test naming conventions
+  - Arrange-Act-Assert pattern
+  - Given-When-Then format
+  - Test isolation
+  - Parameterized tests
+
+data_files:
+  - data/core-tdd-cycle.yaml
+  - data/test-doubles.yaml
+  - data/coverage-strategies.yaml
+  - data/bdd-atdd-patterns.yaml
+  - data/language-patterns.yaml
+  - data/anti-patterns.yaml

package/.agent/skills/cross-cutting/tdd-workflow/SKILL.md

@@ -0,0 +1,128 @@
+# Test-Driven Development (TDD)
+
+> 🧪 **Complete TDD methodology for production-quality code**
+> **Patterns**: 180+ | **Languages**: 12 | **Categories**: 6
+
+---
+
+## Quick Reference
+
+| What You Need                        | Data File                  | Patterns |
+| ------------------------------------ | -------------------------- | -------- |
+| Core TDD cycle (Red-Green-Refactor)  | `core-tdd-cycle.yaml`      | 35       |
+| Test doubles (mock, stub, spy, fake) | `test-doubles.yaml`        | 30       |
+| Coverage strategies                  | `coverage-strategies.yaml` | 25       |
+| BDD/ATDD patterns (Given-When-Then)  | `bdd-atdd-patterns.yaml`   | 30       |
+| Language-specific TDD patterns       | `language-patterns.yaml`   | 45       |
+| TDD anti-patterns to avoid           | `anti-patterns.yaml`       | 15       |
+
+---
+
+## TDD Cycle
+
+```
+┌─────────────────────────────────────────────┐
+│  1. RED    → Write a failing test           │
+│  2. GREEN  → Write minimal code to pass     │
+│  3. REFACTOR → Improve without breaking     │
+│  4. REPEAT → Next requirement               │
+└─────────────────────────────────────────────┘
+```
+
+### Phase Details
+
+| Phase        | Goal                     | Rules                                                    |
+| ------------ | ------------------------ | -------------------------------------------------------- |
+| **RED**      | Define expected behavior | Test MUST fail first. No production code yet             |
+| **GREEN**    | Make it work             | Write the SIMPLEST code that passes. No optimization     |
+| **REFACTOR** | Make it clean            | Remove duplication. Improve naming. All tests still pass |
+
+---
+
+## Test Naming Conventions
+
+| Pattern                                        | Example                                     |
+| ---------------------------------------------- | ------------------------------------------- |
+| `should_[behavior]_when_[condition]`           | `should_throw_when_email_invalid`           |
+| `[method]_[scenario]_[expected]`               | `withdraw_insufficientFunds_throwsError`    |
+| `given_[context]_when_[action]_then_[outcome]` | `given_empty_cart_when_checkout_then_error` |
+| `it [behavior description]`                    | `it returns 404 for missing user`           |
+
+---
+
+## Test Structure (AAA Pattern)
+
+```
+Arrange → Set up test data, dependencies, system state
+Act     → Execute the behavior under test
+Assert  → Verify the expected outcome
+```
+
+---
+
+## Test Doubles
+
+| Type      | Purpose                     | When to Use                     |
+| --------- | --------------------------- | ------------------------------- |
+| **Dummy** | Fill parameter lists        | Satisfy required args, not used |
+| **Stub**  | Return canned answers       | Isolate from dependencies       |
+| **Spy**   | Record interactions         | Verify side-effects             |
+| **Mock**  | Pre-programmed expectations | Behavior verification           |
+| **Fake**  | Simplified implementation   | In-memory DB, fake API          |
+
+---
+
+## Coverage Strategy
+
+| Level           | Target         | Method                |
+| --------------- | -------------- | --------------------- |
+| **Unit**        | 80%+           | TDD cycle             |
+| **Integration** | 60%+           | API/DB boundary tests |
+| **E2E**         | Critical paths | Smoke + regression    |
+| **Mutation**    | 70%+           | Kill mutant score     |
+
+---
+
+## BDD Format
+
+```gherkin
+Feature: User Registration
+  Scenario: Valid registration
+    Given a new user with valid email
+    When they submit the registration form
+    Then account is created
+    And welcome email is sent
+```
+
+---
+
+## Language-Specific TDD
+
+| Language       | Framework   | Runner          | Assert                          |
+| -------------- | ----------- | --------------- | ------------------------------- |
+| **TypeScript** | Jest/Vitest | `npx vitest`    | `expect().toBe()`               |
+| **Python**     | pytest      | `pytest -v`     | `assert`, `pytest.raises`       |
+| **Go**         | testing     | `go test ./...` | `t.Fatal`, testify              |
+| **Rust**       | built-in    | `cargo test`    | `assert_eq!`, `#[should_panic]` |
+| **Java**       | JUnit 5     | `mvn test`      | `assertEquals`, Mockito         |
+| **C#**         | xUnit/NUnit | `dotnet test`   | `Assert.Equal`, Moq             |
+| **C++**        | Google Test | `ctest`         | `EXPECT_EQ`, GMock              |
+| **Swift**      | XCTest      | `swift test`    | `XCTAssertEqual`                |
+| **Kotlin**     | JUnit 5     | `gradle test`   | MockK, kotest                   |
+| **PHP**        | PHPUnit     | `phpunit`       | `$this->assertEquals()`         |
+| **Ruby**       | RSpec       | `rspec`         | `expect().to eq()`              |
+| **Elixir**     | ExUnit      | `mix test`      | `assert`                        |
+
+---
+
+## HSA Integration
+
+Data powered by HSA BM25 search engine. Query YAML data via skill search:
+
+| Domain        | Query Examples                       |
+| ------------- | ------------------------------------ |
+| TDD Cycle     | "red green refactor minimal code"    |
+| Test Doubles  | "mock stub spy fake dummy"           |
+| BDD           | "given when then scenario feature"   |
+| Coverage      | "mutation testing kill score branch" |
+| Anti-patterns | "test coupling brittle flaky slow"   |

package/.agent/skills/cross-cutting/tdd-workflow/data/anti-patterns.yaml

@@ -0,0 +1,70 @@
+# TDD Anti-Patterns
+# Common mistakes and how to fix them
+
+anti_patterns:
+  - name: the-liar
+    description: "Test that passes but doesn't actually verify anything"
+    symptom: "No meaningful assertions, or assert true === true"
+    fix: "Every test must assert the specific expected outcome"
+    severity: critical
+
+  - name: excessive-setup
+    description: "Test requires 50+ lines of setup code"
+    symptom: "Setup is longer than the test itself"
+    fix: "Use factories, builders, or test fixtures. Simplify SUT"
+    severity: high
+
+  - name: the-giant
+    description: "Single test that verifies too many things"
+    symptom: "20+ assertions in one test"
+    fix: "Split into focused tests — one concept per test"
+    severity: high
+
+  - name: the-mockery
+    description: "Mocking everything, testing nothing real"
+    symptom: "Only testing mock interactions, not actual behavior"
+    fix: "Mock boundaries only (DB, API, filesystem). Test logic directly"
+    severity: high
+
+  - name: the-inspector
+    description: "Test tightly coupled to implementation details"
+    symptom: "Test breaks when refactoring internal code"
+    fix: "Test behavior (public API) not implementation"
+    severity: medium
+
+  - name: second-class-citizen
+    description: "Test code treated as less important than production code"
+    symptom: "Copy-paste in tests, no refactoring, poor naming"
+    fix: "Apply same quality standards to test code"
+    severity: medium
+
+  - name: the-slow-poke
+    description: "Tests that take too long to run"
+    symptom: "Full suite takes 10+ minutes"
+    fix: "Mock I/O, use in-memory DB, parallelize tests"
+    severity: medium
+
+  - name: the-free-ride
+    description: "Adding assertions to existing test instead of new test"
+    symptom: "Test name doesn't match what it verifies"
+    fix: "Each test should verify ONE specific behavior"
+    severity: low
+
+  - name: test-after-code
+    description: "Writing tests after implementation (not TDD)"
+    symptom: "Tests match implementation, not requirements"
+    fix: "Write tests FIRST — they should describe behavior"
+    severity: low
+
+  - name: flaky-test
+    description: "Test that fails intermittently"
+    causes:
+      - "Race conditions in async code"
+      - "Shared mutable state between tests"
+      - "Time-dependent logic"
+      - "Network calls in tests"
+    fix:
+      - "Isolate test state"
+      - "Use deterministic clocks"
+      - "Mock external calls"
+      - "Run in isolation"

package/.agent/skills/cross-cutting/tdd-workflow/data/bdd-atdd-patterns.yaml

@@ -0,0 +1,77 @@
+# BDD and ATDD Patterns
+# Behavior-Driven and Acceptance Test-Driven Development
+
+patterns:
+  - name: gherkin-syntax
+    type: bdd
+    description: "Given-When-Then scenarios for behavior specification"
+    format: |
+      Feature: [Business capability]
+        Background: [Shared setup]
+        Scenario: [Specific case]
+          Given [initial context]
+          When [action occurs]
+          Then [expected outcome]
+          And [additional outcome]
+    tools:
+      javascript: "Cucumber.js"
+      python: "behave, pytest-bdd"
+      java: "Cucumber-JVM"
+      ruby: "Cucumber"
+      csharp: "SpecFlow"
+      go: "godog"
+
+  - name: scenario-outline
+    type: bdd
+    description: "Parameterized scenarios for data-driven testing"
+    example: |
+      Scenario Outline: Discount calculation
+        Given a cart with total <total>
+        When discount type is <type>
+        Then final price is <expected>
+        Examples:
+          | total | type      | expected |
+          | 100   | percent10 | 90       |
+          | 200   | flat20    | 180      |
+          | 50    | none      | 50       |
+
+  - name: three-amigos
+    type: atdd
+    description: "Collaborative specification by developer, tester, and business"
+    participants:
+      - role: business
+        focus: "What should happen? Why?"
+      - role: developer
+        focus: "How to implement? Edge cases?"
+      - role: tester
+        focus: "What could go wrong? Missing scenarios?"
+    output: "Agreed acceptance criteria as executable specifications"
+
+  - name: specification-by-example
+    type: atdd
+    description: "Use concrete examples to define behavior"
+    process:
+      - "Derive scope from business goal"
+      - "Specify using key examples"
+      - "Refine examples with stakeholders"
+      - "Automate examples as tests"
+      - "Validate frequently"
+
+  - name: living-documentation
+    type: bdd
+    description: "Tests serve as always-current documentation"
+    benefits:
+      - "Specs are executable — always up to date"
+      - "Non-technical stakeholders can read scenarios"
+      - "Single source of truth for behavior"
+
+  - name: user-story-mapping
+    type: atdd
+    description: "Map user stories to acceptance criteria to tests"
+    flow:
+      - step: "User Story"
+        format: "As a [role], I want [feature], so that [benefit]"
+      - step: "Acceptance Criteria"
+        format: "Given-When-Then scenarios"
+      - step: "Test Cases"
+        format: "Automated BDD/ATDD tests"

package/.agent/skills/cross-cutting/tdd-workflow/data/core-tdd-cycle.yaml

@@ -0,0 +1,104 @@
+# TDD Core Cycle Patterns
+# Red-Green-Refactor methodology
+
+patterns:
+  - name: red-phase-failing-test
+    phase: red
+    description: "Write a failing test that defines desired behavior"
+    rules:
+      - "Test MUST fail before writing production code"
+      - "Test should fail for the RIGHT reason (not syntax/import error)"
+      - "One test at a time — do not batch"
+      - "Test name clearly describes expected behavior"
+    example:
+      language: typescript
+      code: |
+        // RED: Test fails — function doesn't exist yet
+        describe('calculateDiscount', () => {
+          it('should apply 10% discount for orders over $100', () => {
+            const result = calculateDiscount(150);
+            expect(result).toBe(135);
+          });
+        });
+
+  - name: green-phase-minimal-code
+    phase: green
+    description: "Write the SIMPLEST code that makes the test pass"
+    rules:
+      - "Write MINIMAL code — no optimization"
+      - "Hardcode if only one test case exists"
+      - "Don't generalize prematurely"
+      - "All tests must pass (green)"
+    example:
+      language: typescript
+      code: |
+        // GREEN: Simplest possible implementation
+        function calculateDiscount(amount: number): number {
+          return amount * 0.9;
+        }
+
+  - name: refactor-phase-clean
+    phase: refactor
+    description: "Improve code quality without changing behavior"
+    rules:
+      - "All tests MUST still pass after refactoring"
+      - "Remove duplication (DRY)"
+      - "Improve naming and readability"
+      - "Extract functions/classes if needed"
+      - "No new functionality during refactor"
+    checklist:
+      - "Any duplicated code?"
+      - "Are names clear and descriptive?"
+      - "Can any method be simplified?"
+      - "Is the test itself clean?"
+
+  - name: triangulation
+    phase: red
+    description: "Add more test cases to force generalization"
+    when: "Green phase used hardcoded value"
+    example:
+      language: typescript
+      code: |
+        // Triangulate: Force real logic
+        it('should apply 10% for $200 order', () => {
+          expect(calculateDiscount(200)).toBe(180);
+        });
+        it('should NOT apply discount for $50 order', () => {
+          expect(calculateDiscount(50)).toBe(50);
+        });
+
+  - name: baby-steps
+    description: "Take the smallest possible step at each phase"
+    rules:
+      - "Each commit should be tiny and atomic"
+      - "If stuck longer than 5 min, revert and try smaller step"
+      - "Timebox each Red-Green cycle to 10 minutes max"
+
+  - name: transformation-priority-premise
+    description: "Order of code transformations from simple to complex"
+    transformations:
+      - "({}→nil) no code → return nil/null"
+      - "(nil→constant) return a constant"
+      - "(constant→variable) replace constant with variable"
+      - "(unconditional→conditional) add if/else"
+      - "(scalar→collection) single → list/array"
+      - "(statement→recursion) iterate → recurse"
+      - "(value→type) change type representation"
+
+  - name: outside-in-tdd
+    description: "Start from acceptance test, drill down to unit tests"
+    flow:
+      - "Write acceptance test (E2E/integration) — RED"
+      - "Write unit test for first component — RED"
+      - "Implement component — GREEN"
+      - "Repeat for next component"
+      - "Acceptance test passes — done"
+
+  - name: inside-out-tdd
+    description: "Start from domain/core logic, build outward"
+    flow:
+      - "Write unit test for core domain — RED"
+      - "Implement domain logic — GREEN"
+      - "Write integration test — RED"
+      - "Wire up infrastructure — GREEN"
+      - "Add acceptance test at the end"

package/.agent/skills/cross-cutting/tdd-workflow/data/coverage-strategies.yaml

@@ -0,0 +1,105 @@
+# Coverage Strategies
+# Test coverage targets, mutation testing, and coverage metrics
+
+strategies:
+  - name: coverage-pyramid
+    description: "Test pyramid — more unit, fewer E2E"
+    layers:
+      - level: unit
+        target: "80%+"
+        speed: fast
+        count: "70% of all tests"
+      - level: integration
+        target: "60%+"
+        speed: medium
+        count: "20% of all tests"
+      - level: e2e
+        target: "critical paths only"
+        speed: slow
+        count: "10% of all tests"
+
+  - name: coverage-metrics
+    description: "Types of code coverage"
+    metrics:
+      - name: line-coverage
+        measures: "Lines executed"
+        minimum: "80%"
+        note: "Most basic — can be misleading"
+      - name: branch-coverage
+        measures: "If/else branches taken"
+        minimum: "75%"
+        note: "Better than line coverage"
+      - name: condition-coverage
+        measures: "Boolean sub-expressions"
+        minimum: "70%"
+        note: "Catches compound condition gaps"
+      - name: path-coverage
+        measures: "Unique execution paths"
+        minimum: "60%"
+        note: "Most thorough but exponential"
+      - name: mutation-score
+        measures: "% of mutants killed"
+        minimum: "70%"
+        note: "Best quality indicator"
+
+  - name: mutation-testing
+    description: "Verify test quality by introducing bugs"
+    concept: "If tests are good, mutating code should make tests fail"
+    tools:
+      typescript: "Stryker Mutator"
+      python: "mutmut, cosmic-ray"
+      java: "PIT (pitest)"
+      go: "go-mutesting"
+      rust: "cargo-mutants"
+      csharp: "Stryker.NET"
+    mutations:
+      - "Replace + with -"
+      - "Replace > with >="
+      - "Remove method call"
+      - "Replace true with false"
+      - "Remove conditional"
+
+  - name: coverage-anti-patterns
+    description: "Common mistakes in coverage strategy"
+    anti_patterns:
+      - name: "100% coverage obsession"
+        problem: "Diminishing returns past 85%"
+        solution: "Focus on critical path and mutation score"
+      - name: "Coverage without assertions"
+        problem: "Code executes but nothing is verified"
+        solution: "Every test must have meaningful assertions"
+      - name: "Testing getters/setters"
+        problem: "Covering trivial code inflates metrics"
+        solution: "Focus coverage on business logic"
+      - name: "Ignoring edge cases"
+        problem: "High coverage but missing boundaries"
+        solution: "Add boundary value analysis tests"
+
+  - name: what-to-test
+    description: "Priority of what to test"
+    priority:
+      - level: critical
+        items:
+          [
+            "Business logic",
+            "Validation rules",
+            "Security checks",
+            "Financial calculations",
+          ]
+      - level: important
+        items:
+          [
+            "Data transformations",
+            "API contracts",
+            "Error handling",
+            "State transitions",
+          ]
+      - level: nice_to_have
+        items: ["UI rendering", "Configuration loading", "Logging"]
+      - level: skip
+        items:
+          [
+            "Generated code",
+            "Third-party library internals",
+            "Simple getters/setters",
+          ]

package/.agent/skills/cross-cutting/tdd-workflow/data/language-patterns.yaml

@@ -0,0 +1,115 @@
+# Language-Specific TDD Patterns
+# Framework setup and idioms per language
+
+languages:
+  - name: typescript
+    frameworks: ["Jest", "Vitest"]
+    setup:
+      vitest: "npm install -D vitest; npx vitest --init"
+      jest: "npm install -D jest @types/jest ts-jest"
+    tdd_cycle:
+      red: |
+        import { describe, it, expect } from 'vitest';
+        import { add } from './calc';
+        describe('add', () => {
+          it('adds two numbers', () => {
+            expect(add(1, 2)).toBe(3);
+          });
+        });
+      green: |
+        export function add(a: number, b: number): number {
+          return a + b;
+        }
+      run: "npx vitest run"
+
+  - name: python
+    frameworks: ["pytest"]
+    setup: "pip install pytest pytest-cov"
+    tdd_cycle:
+      red: |
+        from calc import add
+        def test_add():
+            assert add(1, 2) == 3
+      green: |
+        def add(a: int, b: int) -> int:
+            return a + b
+      run: "pytest -v --cov=src"
+
+  - name: go
+    frameworks: ["testing (stdlib)"]
+    setup: "Built-in — no install needed"
+    tdd_cycle:
+      red: |
+        func TestAdd(t *testing.T) {
+            got := Add(1, 2)
+            if got != 3 {
+                t.Errorf("Add(1,2) = %d; want 3", got)
+            }
+        }
+      green: |
+        func Add(a, b int) int {
+            return a + b
+        }
+      run: "go test ./... -v -cover"
+
+  - name: rust
+    frameworks: ["built-in"]
+    setup: "Built-in — #[cfg(test)] mod tests"
+    tdd_cycle:
+      red: |
+        #[cfg(test)]
+        mod tests {
+            use super::*;
+            #[test]
+            fn test_add() {
+                assert_eq!(add(1, 2), 3);
+            }
+        }
+      green: |
+        pub fn add(a: i32, b: i32) -> i32 {
+            a + b
+        }
+      run: "cargo test"
+
+  - name: java
+    frameworks: ["JUnit 5", "Mockito"]
+    setup: |
+      <!-- pom.xml -->
+      <dependency>
+        <groupId>org.junit.jupiter</groupId>
+        <artifactId>junit-jupiter</artifactId>
+        <scope>test</scope>
+      </dependency>
+    tdd_cycle:
+      red: |
+        @Test
+        void shouldAddTwoNumbers() {
+            assertEquals(3, Calculator.add(1, 2));
+        }
+      green: |
+        public static int add(int a, int b) {
+            return a + b;
+        }
+      run: "mvn test"
+
+  - name: csharp
+    frameworks: ["xUnit", "NUnit", "Moq"]
+    setup: "dotnet add package xunit"
+    tdd_cycle:
+      red: |
+        [Fact]
+        public void Add_TwoNumbers_ReturnsSum()
+        {
+            Assert.Equal(3, Calculator.Add(1, 2));
+        }
+      run: "dotnet test"
+
+  - name: cpp
+    frameworks: ["Google Test", "Catch2"]
+    setup: "find_package(GTest REQUIRED)"
+    tdd_cycle:
+      red: |
+        TEST(CalculatorTest, AddsTwoNumbers) {
+            EXPECT_EQ(add(1, 2), 3);
+        }
+      run: "cmake --build build && ctest --test-dir build"