nw-tdd-methodology

# Outside-In TDD Methodology ## Double-Loop TDD Architecture Outer loop: ATDD/E2E Tests (customer view) - business requirements, hours-days to green. Inner loop: Unit Tests (developer view) - technical implementation, minutes to green, RED->GREEN->REFACTOR. Outer stays red while inner cycles. Outer drives WHAT to build, inner drives HOW. Never build components not needed by actual user scenarios. ## Outside-In vs Inside-Out Inside-Out (Classic/bottom-up): discovers collaborators through refactoring. TDD guides design completely. Outside-In (London/top-down/mockist): knows collaborators upfront, mocks them, implements each moving inward. Use Outside-In when: architectural boundaries known (hexagonal), program to interface not implementation. ## ATDD Integration (Lightweight) Original 2008 heavyweight ATDD was "too heavyweight for most real teams." Updated approach (Hendrickson 2024): - Few Given/When/Then examples, not many | Separate requirements from tests - Smallest subset of team with relevant skills | Value = shared understanding, not executable specs - Automate only where high-value ## BDD Integration BDD emerged from Outside-In TDD. Given(context)->When(action)->Then(outcome) maps to outside-in mindset. BDD reframes TDD as design/specification technique, not just testing. More accessible to stakeholders. Gherkin: structured format bridging technical/non-technical. Use pragmatically - automate only where high value. ## Outside-In Development Workflow (Bache) 1...