ai-flow-dev 2.2.0 → 2.2.4

package/prompts/mobile/flow-build-phase-6.md

@@ -1,494 +1,524 @@
-# Phase 6: Testing Strategy
+## PHASE 6: Testing Strategy (15-20 min)
 
-**Duration:** 15-25 minutes
-**Questions:** ~12 questions
-**Output:** docs/testing.md, parts of ai-instructions.md
----
-## 🎯 Objective
+> **Order for this phase:**
+>
+> - **MVP:** 6.1 → 6.2 (smoke tests) → 6.7 (CI basics)
+> - **Production-Ready:** 6.1 → 6.1b → 6.2 → 6.3 → 6.4 → 6.5 → 6.6 → 6.7
+> - **Enterprise:** 6.1 → 6.1b → 6.2 → 6.3 → 6.4 → 6.5 → 6.6 → 6.7 → 6.8 → 6.9
 
-Define your mobile testing strategy:
+> **📌 Scope-based behavior:**
+>
+> - **MVP:** Ask 6.1 (framework), 6.2 (smoke tests only), 6.7 (CI basics) - **Target: 15-25% coverage**
+> - **Production-Ready:** Ask all questions 6.1-6.7 - **Target: 60-80% coverage**
+> - **Enterprise:** Ask all questions 6.1-6.9 - **Target: 80-95% coverage + contract/load tests**
 
-1. What testing frameworks will you use?
-2. What types of tests will you write?
-3. How will you test on devices/emulators?
-4. What coverage targets?
-5. How will tests run in CI/CD?
----
-## 📋 Questions
+### Objective
 
-### Question 6.1: Unit Testing Framework
+Define testing approach, tools, and quality gates.
 
-**What unit test framework will you use?**
+**🚨 Important: All projects require basic testing. Scope determines depth, not whether to test.**
 
-**If React Native:**
+---
 
-- A) ⭐ **Jest** (Recommended)
-  - Built-in with React Native
-  - Snapshot testing
-  - Best for: Most React Native apps
+## 🔍 Pre-Flight Check (Smart Skip Logic)
 
-- B) **Vitest**
-  - Faster, ESM native
-  - Best for: Modern setups
+> 📎 **Reference:** See [prompts/shared/smart-skip-preflight.md](../shared/smart-skip-preflight.md) for the complete smart skip logic.
 
-**If Flutter:**
+**Execute Pre-Flight Check for Phase 6:**
 
-- A) ⭐ **Flutter Test** (Built-in)
-  - Widget testing
-  - Unit testing
-  - Best for: All Flutter apps
+- **Target File**: `docs/testing.md`
+- **Phase Name**: "TESTING STRATEGY"
+- **Key Items**: Test framework, coverage targets, test types, CI/CD integration
+- **Typical Gaps**: E2E strategy, load testing, performance testing
 
-**If Native iOS:**
+**Proceed with appropriate scenario based on audit data from `.ai-flow/cache/audit-data.json`**
 
-- A) ⭐ **XCTest** (Built-in)
-  - Unit tests
-  - UI tests
-  - Best for: All iOS apps
+---
 
-**If Native Android:**
+## Phase 6 Questions (Full Mode)
 
-- A) ⭐ **JUnit** (Standard)
-  - Unit tests
-  - Best for: All Android apps
+**6.1 Testing Framework**
 
-**Your answer:**
----
-### Question 6.2: Component/Screen Testing
-
-**How will you test components and screens?**
-
-**If React Native:**
-
-- A) ⭐ **React Native Testing Library** (Recommended)
-  - User-centric testing
-  - Accessible queries
-  - Best for: All React Native apps
-
-**If Flutter:**
-
-- A) ⭐ **Widget Testing** (Built-in)
-  - Test widgets in isolation
-  - Best for: All Flutter apps
-
-**If Native iOS:**
-
-- A) ⭐ **XCUITest** (Built-in)
-  - UI testing framework
-  - Best for: All iOS apps
-
-**If Native Android:**
-
-- A) ⭐ **Espresso** (Recommended)
-  - UI testing framework
-  - Best for: All Android apps
-
-**Your answer:**
----
-### Question 6.3: E2E Testing Framework
-
-**What E2E testing tool will you use?**
-
-**If React Native:**
+```
 
-- A) ⭐ **Detox** (Recommended)
-  - Gray-box E2E testing
-  - Works with iOS and Android
-  - Best for: Most React Native apps
+Which testing tools will you use?
 
-- B) **Maestro**
-  - Declarative E2E testing
-  - Cross-platform
-  - Best for: Simple E2E flows
+JavaScript/TypeScript:
+A) ⭐ Jest - Most popular, great ecosystem
+B) Vitest - Modern, fast, Vite-compatible
+C) Mocha + Chai
+D) AVA
 
-- C) **Appium**
-  - WebDriver-based
-  - Cross-platform
-  - Best for: Complex E2E scenarios
+Python:
+E) ⭐ pytest - Modern, feature-rich
+F) unittest - Built-in
+G) nose2
 
-**If Flutter:**
+Java:
+H) ⭐ JUnit 5 + Mockito
+I) TestNG
 
-- A) ⭐ **Integration Test** (Built-in)
-  - Flutter's integration testing
-  - Best for: Most Flutter apps
+Your choice: \_\_
 
-- B) **Maestro**
-  - Declarative E2E testing
-  - Best for: Simple E2E flows
+Assertion library: **
+Mocking library: **
 
-**If Native:**
+```
 
-- A) ⭐ **Appium** (Recommended)
-  - Cross-platform
-  - Works with iOS and Android
-  - Best for: Native apps
+**6.1b Testing Philosophy** (Production-Ready and Enterprise only)
 
-**Your answer:**
----
-### Question 6.4: Testing on Physical Devices
+```
+What is your testing philosophy?
 
-**How will you test on physical devices?**
+A) ⭐ Test-First (TDD) - Write tests before code
+   - Red-Green-Refactor cycle
+   - Higher initial effort, better design
+   - Best for: Complex business logic, critical systems
 
-A) ⭐ **TestFlight (iOS) + Firebase App Distribution (Android)** (Recommended)
+B) 🔥 Test-After - Write tests after implementation
+   - Faster initial development
+   - Risk of untested edge cases
+   - Best for: Rapid prototyping, time-sensitive features
 
-- Beta testing on real devices
-- Best for: Most apps
+C) ⚡ Behavior-Driven (BDD) - Write tests as specifications
+   - Given/When/Then format
+   - Business-readable tests
+   - Best for: Domain-heavy applications
 
-B) **TestFlight (iOS) + Google Play Internal Testing (Android)**
+D) 🏆 Hybrid - TDD for core logic, test-after for simple features
+   - Balance of speed and quality
+   - Pragmatic approach
 
-- Official store channels
-- Best for: Store-focused testing
+Your choice: __
+```
 
-C) **Device Farm Services**
+**6.2 Test Types**
 
-- AWS Device Farm
-- BrowserStack App Automate
-- Sauce Labs
-- Best for: Multiple device testing
+```
+[If MVP scope selected, ask simplified version:]
 
-D) **Manual Testing Only**
+For MVP, we'll focus on smoke tests (critical path verification).
+Which critical flows should be tested?
 
-- Test on personal devices
-- Best for: Small teams, MVPs
+Select 3-5 most important endpoints/features:
+A) Authentication (login/register)
+B) Main business operation (e.g., create order, post article)
+C) User profile/account management
+D) Payment processing (if applicable)
+E) Data retrieval (main GET endpoints)
 
-**Your answer:**
----
-### Question 6.5: Emulator/Simulator Strategy
+Selected: __
 
-**How will you use emulators/simulators?**
+Test approach: Integration tests covering happy path of selected flows
+Coverage target: 15-25%
+Test type: Integration/E2E only (no unit tests required for MVP)
 
-A) ⭐ **Local Emulators + CI Emulators** (Recommended)
+[If Production-Ready or Enterprise scope selected, ask full version:]
 
-- Develop locally with iOS Simulator / Android Emulator
-- Run tests in CI with emulators
-- Best for: Most teams
+Which test types will you implement?
 
-B) **Local Only**
+A) ✅ Unit Tests
+   - Test individual functions/methods in isolation
+   - Fast, numerous
+   - Mock all dependencies
 
-- No CI emulator testing
-- Best for: Small teams
+B) ✅ Integration Tests
+   - Test multiple components together
+   - Database, external APIs
+   - Slower but more realistic
 
-C) **Cloud Emulators Only**
+C) ✅ E2E (End-to-End) Tests
+   - Test full user flows
+   - API endpoints from request to response
+   - Tool: Supertest (Node.js), pytest with TestClient (Python)
 
-- Use cloud services for all testing
-- Best for: Teams without local setup
+D) 🏆 Contract Tests (Advanced - Enterprise recommended)
+   - Verify API contracts between services
+   - Tool: Pact, Spring Cloud Contract
 
-**Your answer:**
----
-### Question 6.6: Testing Pyramid Distribution
+E) ⚡ Load/Performance Tests (Enterprise recommended)
+   - Tool: Artillery, K6, JMeter
 
-**What test distribution will you target?**
+F) 🔬 Chaos Engineering (Enterprise only)
+   - Test system resilience to failures
+   - Tool: Chaos Monkey, Litmus, Gremlin
 
-A) ⭐ **Standard Pyramid** (Recommended)
+Selected: __
 
+Pyramid distribution:
 - 70% Unit tests
 - 20% Integration tests
 - 10% E2E tests
-- Best for: Most apps
-
-B) **Heavy Unit**
+  (Adjust as needed)
 
-- 85% Unit tests
-- 10% Integration tests
-- 5% E2E tests
-- Best for: Logic-heavy apps
+```
 
-C) **Heavy Integration**
+**6.3 Test Database** [Skip if MVP scope]
 
-- 50% Unit tests
-- 40% Integration tests
-- 10% E2E tests
-- Best for: UI-heavy apps
+```
+[Production-Ready/Enterprise only]
 
-**Your answer:**
----
-#### 🎨 MOBILE TESTING PYRAMID VISUALIZATION
+How will you handle database in tests?
 
-**Use this diagram format** to visualize mobile test distribution strategy:
+A) ⭐ In-memory database
+   - SQLite for testing, PostgreSQL for prod
+   - Fast, isolated
 
-```mermaid
-graph TB
-    subgraph "Mobile Testing Pyramid"
-        E2E["📱 E2E Tests (10%)<br/>Detox/Appium<br/>Slow, Expensive<br/>Full user flows on device"]
-        INT["🔗 Integration Tests (20%)<br/>Component + API<br/>Medium Speed<br/>Screen rendering + navigation"]
-        UNIT["⚡ Unit Tests (70%)<br/>Jest/XCTest<br/>Fast, Cheap<br/>Business logic, hooks, utilities"]
-    end
+B) 🏆 Docker test database
+   - Same DB as production
+   - More realistic
+   - Tool: Testcontainers
 
-    E2E --> INT
-    INT --> UNIT
+C) 🔄 Shared test database
+   - One DB for all tests
+   - Reset between test suites
 
-    style E2E fill:#fce4ec,stroke:#c2185b,stroke-width:2px
-    style INT fill:#fff4e6,stroke:#f57c00,stroke-width:2px
-    style UNIT fill:#e8f5e9,stroke:#388e3c,stroke-width:3px
+D) 🎭 Mock database
+   - Mock all DB calls
+   - Fastest, but less realistic
 
-    classDef note fill:#f5f5f5,stroke:#666,stroke-dasharray: 5 5
+Your choice: __
 
-    note1["Run on Real Devices/Emulators<br/>Test platform-specific behavior<br/>Slow feedback (minutes)"]:::note
-    note2["Test screen components<br/>Navigation flows<br/>API integration<br/>Medium feedback"]:::note
-    note3["Test pure functions<br/>Redux reducers<br/>Utilities, validators<br/>Fast feedback (seconds)"]:::note
+Test data strategy:
+A) ⭐ Factories/Fixtures - Generate test data programmatically
+B) Seed files - Load from JSON/SQL files
+C) Inline - Create data in each test
 
-    E2E -.-> note1
-    INT -.-> note2
-    UNIT -.-> note3
 ```
 
-**Mobile-Specific Testing Layers:**
-
-```mermaid
-graph TB
-    subgraph "Mobile Test Types"
-        E2E_LAYER["E2E Layer<br/>Detox, Maestro, Appium"]
-        SCREEN_LAYER["Screen Tests<br/>React Native Testing Library<br/>Flutter Widget Tests"]
-        COMPONENT_LAYER["Component Tests<br/>Rendering, Props, Events"]
-        LOGIC_LAYER["Unit Tests<br/>Hooks, Utils, State Logic"]
-        STATIC_LAYER["Static Analysis<br/>TypeScript, ESLint"]
-    end
-
-    E2E_LAYER --> SCREEN_LAYER
-    SCREEN_LAYER --> COMPONENT_LAYER
-    COMPONENT_LAYER --> LOGIC_LAYER
-    LOGIC_LAYER --> STATIC_LAYER
-
-    DEVICES["Real Devices<br/>iOS + Android"]
-    EMULATORS["Emulators/Simulators<br/>Fast feedback"]
-
-    E2E_LAYER -.->|Run on| DEVICES
-    SCREEN_LAYER -.->|Run on| EMULATORS
-
-    style E2E_LAYER fill:#fce4ec,stroke:#c2185b,stroke-width:2px
-    style SCREEN_LAYER fill:#fff4e6,stroke:#f57c00,stroke-width:2px
-    style COMPONENT_LAYER fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
-    style LOGIC_LAYER fill:#e1f5ff,stroke:#1976d2,stroke-width:2px
-    style STATIC_LAYER fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
+**6.4 Test Data Management** [Skip if MVP scope]
+
 ```
+[Production-Ready/Enterprise only]
 
-**Platform-Specific Testing Considerations:**
+How will you create test data?
 
-```mermaid
-graph LR
-    subgraph "Cross-Platform Mobile Testing"
-        SHARED[Shared Business Logic<br/>Unit Tests (Jest)]
-        RN_SCREEN[React Native<br/>Screen Tests]
-        FLUTTER_WIDGET[Flutter<br/>Widget Tests]
-    end
+A) ⭐ Factory pattern
+   - Libraries: factory_boy (Python), Fishery (TypeScript)
+   - Generate realistic data on demand
 
-    subgraph "Platform Tests"
-        IOS_E2E[iOS E2E<br/>XCUITest/Detox]
-        ANDROID_E2E[Android E2E<br/>Espresso/Detox]
-    end
+B) Fixtures
+   - Predefined test data
+   - Loaded before tests
 
-    SHARED --> RN_SCREEN
-    SHARED --> FLUTTER_WIDGET
+C) Faker
+   - Random realistic data
+   - Library: @faker-js/faker, Faker (Python)
 
-    RN_SCREEN --> IOS_E2E
-    RN_SCREEN --> ANDROID_E2E
+Your approach: __
 
-    FLUTTER_WIDGET --> IOS_E2E
-    FLUTTER_WIDGET --> ANDROID_E2E
+Example test data needs:
+- Users with various roles
+- Products with different states
+- Orders in different stages
+- Payment records
+- [Add your specific needs]
 
-    style SHARED fill:#e8f5e9
-    style RN_SCREEN fill:#e1f5ff
-    style FLUTTER_WIDGET fill:#e1f5ff
-    style IOS_E2E fill:#fce4ec
-    style ANDROID_E2E fill:#fff4e6
 ```
 
-**When to Use Each Diagram:**
+**6.5 Mocking Strategy** [Skip if MVP scope]
 
-- **Testing Pyramid**: Best for understanding test distribution strategy
-- **Mobile Test Types**: Best for showing all testing layers including emulators/devices
-- **Cross-Platform**: Best for React Native/Flutter apps with shared logic
+```
+[Production-Ready/Enterprise only]
 
-**Diagram Guidelines:**
+What will you mock?
 
-- Color code by test type (E2E=pink, Integration=orange, Unit=green)
-- Show device vs emulator distinction
-- Include platform-specific considerations (iOS/Android)
-- Highlight speed/cost trade-offs
-- Update percentages based on selected strategy (A, B, or C)
----
----
-### Question 6.7: Code Coverage Targets
+A) ✅ External APIs - Third-party services
+B) ✅ Database - In unit tests
+C) ✅ File system - S3, local storage
+D) ✅ Time/Date - For deterministic tests
+E) ✅ Email/SMS - Sending services
+F) ✅ Payment gateways
 
-**What code coverage targets will you set?**
+Mocking approach:
+A) ⭐ Manual mocks - jest.fn(), unittest.mock
+B) Library - MSW (Mock Service Worker), nock
+C) Test doubles - Stubs, spies, mocks
 
-A) ⭐ **80% Overall** (Recommended)
+When NOT to mock:
+- Internal business logic
+- Simple utilities
+- Value objects
 
-- 80% line coverage
-- 70% branch coverage
-- Best for: Most apps
+```
 
-B) **90% Overall**
+**6.6 Test Organization** [Skip if MVP scope]
 
-- 90% line coverage
-- 80% branch coverage
-- Best for: Critical apps
+```
+[Production-Ready/Enterprise only]
 
-C) **70% Overall**
+Test file structure:
 
-- 70% line coverage
-- 60% branch coverage
-- Best for: MVPs, small apps
+A) ⭐ Co-located with source
+```
 
-D) **No Coverage Target**
+src/
+users/
+user.service.ts
+user.service.spec.ts
 
-- Test what's important
-- Best for: Very small projects
+```
 
-**Your answer:**
----
-### Question 6.8: Snapshot Testing
+B) Separate test directory
+```
 
-**Will you use snapshot testing?**
+src/users/user.service.ts
+tests/users/user.service.test.ts
 
-**If React Native:**
+````
 
-- A) ⭐ **Yes - Jest Snapshots** (Recommended)
-  - Catch unintended UI changes
-  - Best for: Component regression testing
+Test naming:
 
-- B) **No Snapshot Testing**
-  - Manual visual review
-  - Best for: Rapidly changing UIs
+```typescript
+describe('UserService', () => {
+  describe('createUser', () => {
+    it('should create a new user with valid data', async () => {
+      // Arrange
+      const userData = { email: 'test@example.com', name: 'Test' };
 
-**If Flutter:**
+      // Act
+      const result = await userService.createUser(userData);
 
-- A) ⭐ **Yes - Golden Tests** (Recommended)
-  - Flutter's snapshot testing
-  - Best for: Widget regression testing
+      // Assert
+      expect(result).toBeDefined();
+      expect(result.email).toBe(userData.email);
+    });
 
-**Your answer:**
----
-### Question 6.9: Performance Testing
+    it('should throw error when email is duplicated', async () => {
+      // ...
+    });
+  });
+});
+````
 
-**Will you test app performance?**
+Naming pattern:
+A) ⭐ "should [expected behavior] when [condition]"
+B) "it [expected behavior]"
+C) Free-form
 
-A) ⭐ **Yes - Basic Performance** (Recommended)
+````
 
-- App launch time
-- Screen render time
-- Memory usage
-- Best for: Most apps
+**6.6.1 Contract Testing** [If selected in 6.2]
 
-B) **Yes - Comprehensive Performance**
+```
+[Production-Ready/Enterprise only]
+
+Contract testing tool:
+A) ⭐ Pact - Consumer-driven contracts
+B) Spring Cloud Contract - Provider contracts
+C) Other: __
+
+Contract strategy:
+A) ⭐ Consumer-driven - Frontend/consumers define contracts
+B) Provider-driven - Backend defines contracts
+C) Both - Hybrid approach
+
+Contract storage:
+A) ⭐ Pact Broker - Centralized contract storage
+B) Git repository - Version contracts in code
+C) Other: __
+
+Contract versioning:
+- Strategy: __
+- Breaking changes: __
+```
 
-- FPS monitoring
-- Network performance
-- Battery usage
-- Best for: Performance-critical apps
+**6.6.2 Load/Performance Testing** [If selected in 6.2]
 
-C) **No Performance Testing**
+```
+[Production-Ready/Enterprise only]
+
+Load testing tool:
+A) ⭐ Artillery - Node.js, YAML-based
+B) K6 - Modern, JavaScript-based
+C) JMeter - Java-based, GUI available
+D) Locust - Python-based
+E) Other: __
+
+Test scenarios:
+- Normal load: __ requests/second
+- Peak load: __ requests/second
+- Stress test: __ requests/second (beyond capacity)
+- Duration: __ minutes
+
+Performance thresholds:
+- Response time p50: < __ ms
+- Response time p95: < __ ms
+- Response time p99: < __ ms
+- Error rate: < __%
+- Throughput: > __ requests/second
+
+When to run:
+A) ⭐ Before major releases
+B) Weekly automated runs
+C) On-demand only
+```
 
-- Manual testing only
-- Best for: MVPs
+**6.6.3 Chaos Engineering** [If selected in 6.2 - Enterprise only]
 
-**Your answer:**
----
-### Question 6.10: Accessibility Testing
+```
+[Enterprise only]
+
+Chaos engineering tool:
+A) ⭐ Chaos Monkey (Netflix)
+B) Litmus (Kubernetes)
+C) Gremlin - Managed chaos platform
+D) Custom scripts
+E) Other: __
+
+Chaos experiments to run:
+A) Network latency injection
+B) Service failures
+C) Database connection failures
+D) CPU/memory exhaustion
+E) Disk space issues
+F) Network partition
+
+→ Your selection (e.g., A, B, C): __
+
+Safety rules:
+- Run only in: [Staging, Production with approval]
+- Blast radius: __% of traffic/instances
+- Auto-rollback: [Yes/No]
+- Approval required: [Yes/No]
+```
 
-**Will you test accessibility?**
+**6.7 CI/CD Testing** [All scopes - simplified for MVP]
 
-A) ⭐ **Yes - Basic Accessibility** (Recommended)
+```
+[If MVP scope:]
+For MVP, we'll set up basic CI to run smoke tests.
 
-- Screen reader support (TalkBack/VoiceOver)
-- Touch target sizes
-- Color contrast
-- Best for: Most apps
+When will smoke tests run?
+A) ⭐ On pull request (GitHub Actions, GitLab CI) - Recommended
+B) Before deploy only
 
-B) **Yes - Comprehensive Accessibility**
+Selected: __
 
-- WCAG 2.1 AA compliance
-- Full accessibility audit
-- Best for: Public-facing apps
+Quality gate for MVP:
+- ✅ All smoke tests must pass
+- ⚠️ Coverage tracking (no minimum required)
 
-C) **No Accessibility Testing**
+[If Production-Ready or Enterprise scope:]
 
-- Not a priority
-- Best for: Internal apps
+When will tests run?
 
-**Your answer:**
----
-### Question 6.11: CI/CD Testing Strategy
+A) ⭐ On every commit (pre-commit hook) - Catch issues early
+B) 🔥 On pull request (GitHub Actions, GitLab CI) - Most popular, prevents broken merges
+C) ⭐ Before deploy (staging pipeline) - Recommended safety check
+D) Nightly (comprehensive test suite) - For slow/extensive tests
 
-**How will tests run in CI/CD?**
+Selected: __
 
-A) ⭐ **Run All Tests on PR** (Recommended)
+Quality gates:
 
-- Unit tests: Fast (<5 min)
-- Integration tests: Medium (<15 min)
-- E2E tests: Slow (<30 min)
-- Best for: Most teams
+- ✅ All tests must pass
+- ✅ Coverage must be >= __% (15-25% MVP, 60-80% Production, 80-95% Enterprise)
+- ✅ No linting errors
+- ⚡ Performance benchmarks met (optional, Enterprise recommended)
 
-B) **Run Unit Tests on PR, E2E on Merge**
+Failing a quality gate:
+A) ⭐ Block merge/deploy - Force fix
+B) ⚠️ Warning only - Allow with justification
 
-- Faster PR feedback
-- E2E on main branch
-- Best for: Large teams
+```
 
-C) **Run Tests Manually**
+### Phase 6 Output
 
-- No automated testing
-- Best for: Very small teams
+```
+📋 PHASE 6 SUMMARY:
+
+**If MVP scope (A):**
+Testing Framework: [Jest/pytest/JUnit] (6.1)
+Test Types: Smoke tests on critical paths [selected 3-5 critical flows] (6.2)
+Test Approach: Integration/E2E tests covering happy path only (6.2)
+Coverage Target: 15-25% (6.2)
+CI/CD Testing: [on PR/before deploy] + quality gate: all tests must pass (6.7)
+Status: Basic testing implemented for MVP
+
+**If Production-Ready (B):**
+Testing Framework: [Jest/pytest/JUnit + assertion library + mocking library] (6.1)
+Test Types: [unit/integration/e2e - selected types] (6.2)
+Test Distribution: [pyramid percentages: 70/20/10 or custom] (6.2)
+Test Database: [in-memory/Docker/shared/mock + initial data strategy] (6.3)
+Test Data Management: [factories/fixtures/faker approach + specific test data needs] (6.4)
+Mocking Strategy: [what to mock (APIs/DB/files/time/email/payments) + approach] (6.5)
+Test Organization: [co-located/separate folder + naming pattern] (6.6)
+CI/CD Testing: [when tests run (commit/PR/deploy/nightly) + quality gates (pass/60-80% coverage/lint) + gate behavior (block/warn)] (6.7)
+Status: Comprehensive testing strategy implemented
+
+**If Enterprise (C):**
+Testing Framework: [Jest/pytest/JUnit + assertion library + mocking library] (6.1)
+Test Types: [unit/integration/e2e/contract/load/chaos - all types] (6.2)
+Test Distribution: [pyramid percentages: 70/20/10 or custom] (6.2)
+Test Database: [in-memory/Docker/shared/mock + initial data strategy] (6.3)
+Test Data Management: [factories/fixtures/faker approach + specific test data needs] (6.4)
+Mocking Strategy: [what to mock (APIs/DB/files/time/email/payments) + approach] (6.5)
+Test Organization: [co-located/separate folder + naming pattern] (6.6)
+Contract Testing: [tool (Pact/Spring Cloud Contract) + strategy + storage + versioning] (6.6.1)
+Load Testing: [tool (Artillery/K6/JMeter) + scenarios + thresholds + schedule] (6.6.2)
+Chaos Engineering: [tool (Chaos Monkey/Litmus/Gremlin) + experiments + safety rules] (6.6.3)
+CI/CD Testing: [when tests run (commit/PR/deploy/nightly) + quality gates (pass/80-95% coverage/lint/performance) + gate behavior (block/warn)] (6.7)
+Status: Exhaustive testing strategy with advanced scenarios
+
+Is this correct? (Yes/No)
+```
+---
+### 📄 Generate Phase 6 Documents
 
-**Your answer:**
----
-### Question 6.12: Test Data Management
+**Before starting generation:**
 
-**How will you manage test data?**
+```
+📖 Loading context from previous phases...
+✅ Re-reading docs/code-standards.md
+✅ Re-reading ai-instructions.md
+```
 
-A) ⭐ **Mock Data + Test Fixtures** (Recommended)
+**Generate `docs/testing.md` automatically:**
 
-- Mock API responses
-- Use fixtures for consistent data
-- Best for: Most apps
+- Use template: `.ai-flow/templates/docs/testing.template.md`
+- **If MVP scope:** Fill with basic testing strategy: framework selection, smoke tests on critical paths, coverage 15-25%, basic CI setup. Mark advanced sections as "Not implemented yet - expand when moving to Production-Ready"
+- **If Production-Ready:** Fill with comprehensive testing strategy: framework, unit/integration/e2e tests, 60-80% coverage, test data management, mocking, full CI/CD
+- **If Enterprise:** Fill with exhaustive testing strategy: all Production-Ready items + contract tests, load tests, security tests, 80-95% coverage, performance benchmarks
+- Write to: `docs/testing.md`
 
-B) **Test Database**
+```
+✅ Generated: docs/testing.md
 
-- Separate test database
-- Best for: Integration testing
+Document has been created with all Phase 6 information.
 
-C) **Real API (Staging)**
+📝 Would you like to make any corrections before continuing?
 
-- Use staging environment
-- Best for: E2E testing
+→ If yes: Edit the file and type "ready" when done. I'll re-read it.
+→ If no: Type "continue" to proceed to Phase 7.
+```
 
-**Your answer:**
----
-## ✅ Phase 6 Completion
+**If user edits file:**
+Re-read file to refresh context before continuing.
+---
+**Proceed to Phase 7 only after documents are validated.**
 
-After answering all questions, summarize:
+> ⚠️ **CRITICAL:** DO NOT generate README.md in this phase. README.md is ONLY generated in Phase 8 (step 8.5) after framework initialization.
+---
 
-```
----
-✅ Phase 6 Complete: Testing Strategy
----
-Selected Testing Stack:
-- Unit Tests: Jest (React Native Testing Library)
-- E2E Tests: Detox
-- Device Testing: TestFlight + Firebase App Distribution
-- Coverage Target: 80% overall
-- Snapshot Testing: Yes (Jest Snapshots)
-- Performance Testing: Basic
-- Accessibility Testing: Basic
-- CI/CD: Run all tests on PR
-
-Proceed to Phase 7 (Store Deployment)? (Y/n)
-```
----
 ## 📝 Generated Documents
 
 After Phase 6, generate/update:
+- `docs/testing.md` - Testing strategy and quality gates
+
+---
 
-- `docs/testing.md` - Testing strategy and setup guide
-- `ai-instructions.md` - Add testing rules
----
-**Next Phase:** Phase 7 - Store Deployment
+**Next Phase:** Phase 7 - Operations & Deployment (10-15 min)
 
-Read: `.ai-flow/prompts/mobile/flow-build-phase-7-deployment.md`
----
-**Last Updated:** 2025-01-XX
+Read: `.ai-flow/prompts/backend/flow-build-phase-7.md`
 
-**Version:** 1.4.0
+---
 
+**Last Updated:** 2025-12-20
+**Version:** 2.1.8
 
+---
 
+## PHASE 7: Operations & Deployment (10-15 min)
 
+````