Apollo 7.0单元测试常见问题解析

Question

在使用Apollo 7.0进行单元测试时，一个常见的问题是**如何正确模拟Apollo模块间的依赖关系？** 由于Apollo框架中各模块高度解耦、通信频繁，单元测试中若未正确模拟（mock）模块间通信（如通过cyber RT的通道机制），测试用例容易出现不可控或失败的情况。 开发者常遇到的误区包括：未充分了解cyber RT的消息发布/订阅机制导致mock失效，或使用不当的mock工具造成测试脆弱。 正确做法是结合Google Mock框架，对涉及通信的接口进行抽象和替换，确保测试仅关注当前模块逻辑。 此外，Apollo 7.0中引入了更复杂的感知与规划模块交互逻辑，对这些模块进行单元测试时，模拟策略的合理性尤为关键。

Answer 1

1. 单元测试中的依赖模拟：从基础概念谈起

在 Apollo 7.0 的开发中，模块之间的通信机制基于 Cyber RT 构建的实时通信框架。每个模块通过消息通道（Channel）进行发布/订阅通信，实现高度解耦的设计。然而，在单元测试中，这种设计带来了挑战：模块之间的依赖关系难以控制。

常见的误区包括：

• 直接使用真实的模块实例进行测试，导致测试结果不可控
• 使用非类型安全的 mock 工具，导致接口调用与实际运行不一致
• 未理解 Cyber RT 的异步通信机制，导致 mock 不生效或行为不一致

因此，正确的做法是引入接口抽象层（Interface Abstraction），结合 Google Mock 框架进行依赖模拟，确保测试仅聚焦于当前模块逻辑。

2. 接口抽象与 Mock 框架的结合使用

为了正确模拟模块间依赖，首先需要对接口进行抽象。以感知模块向规划模块发送障碍物信息为例：

class PerceptionInterface {
public:
    virtual ~PerceptionInterface() = default;
    virtual void SendObstacles(const ObstacleList& obstacles) = 0;
};
    

然后在实际模块中使用该接口：

class PlanningModule {
public:
    PlanningModule(std::shared_ptr perception)
        : perception_(perception) {}

    void OnObstacleUpdate(const ObstacleList& obstacles) {
        perception_->SendObstacles(obstacles);
        // 执行规划逻辑
    }

private:
    std::shared_ptr perception_;
};
    

在单元测试中，使用 Google Mock 实现接口的 mock：

class MockPerception : public PerceptionInterface {
public:
    MOCK_METHOD(void, SendObstacles, (const ObstacleList&));
};
    

测试用例示例：

TEST(PlanningModuleTest, ObstacleReceived_ShouldCallPerception) {
    auto mock_perception = std::make_shared();
    PlanningModule planner(mock_perception);

    ObstacleList test_obstacles;
    // 填充测试数据

    EXPECT_CALL(*mock_perception, SendObstacles(test_obstacles));
    planner.OnObstacleUpdate(test_obstacles);
}
    

3. Cyber RT 通信机制对测试的影响分析

Cyber RT 使用异步的消息传递机制，模块间通过 Channel 进行通信。在单元测试中，这种异步行为可能导致：

• 测试逻辑无法及时感知消息是否发送
• 消息顺序混乱导致断言失败
• 测试执行时间不稳定

为解决这些问题，建议：

1. 将 Cyber RT 的通信接口抽象为可注入的接口类
2. 在测试中使用同步模拟对象，确保消息顺序可控
3. 使用 Google Mock 的 Times、After 等特性控制调用顺序和频率

例如，模拟 Cyber RT 的 Channel 接口：

class MockChannel {
public:
    virtual ~MockChannel() = default;
    MOCK_METHOD(void, Publish, (const std::string&));
};
    

在测试中验证消息是否按预期发布。

4. 感知与规划模块交互的测试策略

Apollo 7.0 中感知与规划模块的交互逻辑更加复杂，涉及多源数据融合、动态障碍物预测等高级功能。测试时需注意：

• 感知模块输出的格式与规划模块期望输入的格式是否一致
• 模块间通信是否包含必要的元信息（如时间戳、置信度）
• 异常情况下的行为是否符合预期（如感知数据丢失）

推荐测试策略包括：

测试场景	模拟方式	预期行为
正常障碍物输入	Mock 返回固定障碍物列表	规划模块生成安全路径
空输入	Mock 返回空列表	规划模块继续使用上一帧数据
感知数据延迟	Mock 返回带旧时间戳的数据	规划模块忽略该数据

通过上述方式，可以有效验证模块间的交互逻辑。

5. 综合实践：构建可维护的测试架构

为保证测试代码的可维护性，建议采用以下架构设计：

Test Architecture:
    - Interface Abstraction Layer
        - 每个外部依赖接口独立抽象
    - Mock Implementations
        - 使用 Google Mock 实现接口
    - Test Fixture
        - 集成多个 mock，构建模块测试上下文
    - Test Cases
        - 针对不同场景编写测试逻辑
    

使用 SetUp() 方法初始化测试环境：

class PlanningModuleTestFixture : public ::testing::Test {
protected:
    void SetUp() override {
        mock_perception_ = std::make_shared();
        planner_ = std::make_unique(mock_perception_);
    }

    std::shared_ptr mock_perception_;
    std::unique_ptr planner_;
};
    

测试用例示例：

TEST_F(PlanningModuleTestFixture, EmptyObstacleList_ShouldNotPlan) {
    ObstacleList empty_list;
    EXPECT_CALL(*mock_perception_, SendObstacles(empty_list));
    planner_->OnObstacleUpdate(empty_list);
}
    

通过结构化测试设计，提升测试代码的可读性和可维护性。

6. 流程图：模块依赖模拟测试流程

以下是 Apollo 7.0 模块依赖模拟测试的整体流程：

graph TD
            A[识别模块依赖] --> B[定义接口抽象]
            B --> C[实现接口Mock]
            C --> D[构建测试上下文]
            D --> E[编写测试用例]
            E --> F[执行测试]
            F --> G{测试通过?}
            G -- 是 --> H[提交代码]
            G -- 否 --> I[调试并修复]
            I --> D