# Phase 4: End-to-End (E2E) 测试计划与执行方案

## 1. 测试目标
本次 E2E 测试旨在验证系统在“全链路真实环境”下的行为，涵盖**正常流程**、**异常恢复**及**组件动态插拔**场景。不涉及前端 UI，而是通过模拟 HTTP/SSE 客户端直接与后端交互。

核心验证点：
1.  **业务闭环**: 从 `POST /start` 到 SSE 接收 `WorkflowCompleted` 再到最终报告生成。
2.  **状态一致性**: Orchestrator 重启后，能否通过 `SyncStateCommand` 恢复上下文并继续执行。
3.  **容错机制**: 当部分 Data Provider 下线时，策略引擎是否按预期工作（如 "At least one provider"）。
4.  **并发稳定性**: 多个 Workflow 同时运行时互不干扰。

## 2. 测试环境架构
测试运行器 (`end-to-end` Rust Crate) 将作为外部观察者和控制器。

```mermaid
graph TD
    TestRunner[Rust E2E Runner] -->|HTTP/SSE| Gateway[API Gateway]
    TestRunner -->|Docker API| Docker[Docker Engine]
    
    subgraph "Docker Compose Stack"
        Gateway --> Orchestrator
        Orchestrator --> NATS
        NATS --> Providers
        NATS --> ReportGen
        Providers --> Postgres
    end
    
    Docker -.->|Stop/Start| Orchestrator
    Docker -.->|Stop/Start| Providers
```

## 3. 详细测试场景 (Scenarios)

### Scenario A: The Happy Path (基准测试)
*   **目标**: 验证标准流程无误。
*   **步骤**:
    1.  发送 `POST /api/v2/workflow/start` (Symbol: AAPL/000001.SZ)。
    2.  建立 SSE 连接监听 `events.workflow.{id}`。
    3.  验证接收到的事件序列：
        *   `WorkflowStarted` (含完整 DAG)
        *   `TaskStateChanged` (Pending -> Running -> Completed)
        *   `TaskStreamUpdate` (Report 内容流式传输)
        *   `WorkflowCompleted`
    4.  **断言**: 最终报告内容非空，数据库中存在 Analysis 记录。

### Scenario B: Brain Transplant (Orchestrator 宕机恢复)
*   **目标**: 验证 Orchestrator 的状态持久化与快照恢复能力。
*   **步骤**:
    1.  启动 Workflow。
    2.  等待至少一个 Data Fetch Task 完成 (Receiving `TaskCompleted`)。
    3.  **Action**: `docker stop workflow-orchestrator-service`。
    4.  等待 5 秒，**Action**: `docker start workflow-orchestrator-service`。
    5.  Test Runner 重新建立 SSE 连接 (自动触发 `SyncStateCommand`)。
    6.  **断言**:
        *   收到 `WorkflowStateSnapshot` 事件。
        *   快照中已完成的任务状态保持 `Completed`。
        *   流程继续向下执行，直到最终完成。

### Scenario C: Partial Failure (组件拔插)
*   **目标**: 验证 "At least one provider" 容错策略。
*   **步骤**:
    1.  **Action**: `docker stop tushare-provider-service` (模拟 Tushare 挂掉)。
    2.  启动 Workflow (Symbol: 000001.SZ，需涉及 Tushare)。
    3.  **断言**:
        *   Tushare 对应的 Task 状态变为 `Failed` 或 `Skipped`。
        *   由于还有其他 Provider (或模拟数据)，Orchestrator 判定满足 "At least one" 策略。
        *   下游 Analysis Task **正常启动** (而不是被 Block)。
        *   流程最终显示 `WorkflowCompleted` (可能带有 Warning)。
    4.  **Cleanup**: `docker start tushare-provider-service`。

### Scenario D: Network Jitter (网络中断模拟)
*   **目标**: 验证 Gateway 到 Orchestrator 通讯中断后的恢复。
*   **步骤**:
    1.  启动 Workflow。
    2.  Test Runner 主动断开 SSE 连接。
    3.  等待 10 秒。
    4.  Test Runner 重连 SSE。
    5.  **断言**: 立即收到 `WorkflowStateSnapshot`，且补齐了断连期间产生的状态变更。

## 4. 工程实现 (Rustic Implementation)
新建独立 Rust Crate `tests/end-to-end`，不依赖现有 workspace 的构建配置，独立编译运行。

**依赖栈**:
*   `reqwest`: HTTP Client
*   `eventsource-stream` + `futures`: SSE Handling
*   `bollard`: Docker Control API
*   `tokio`: Async Runtime
*   `anyhow`: Error Handling
*   `serde`: JSON Parsing

**执行方式**:
```bash
# 在 tests/end-to-end 目录下
cargo run -- --target-env test
```

