第327篇单元测试实战——Google Test在机器人项目中的应用

郑伟强dev

12人浏览 · 2026-09-01 09:01:15

郑伟强dev · 2026-09-01 09:01:15 发布

上篇聊了端侧AI部署的工程实践。模型部署到嵌入式设备后，你怎么保证推理代码的正确性？换个模型版本，输出还一致吗？精度量化后数值偏差在可接受范围内吗？

这些问题的答案都指向同一个东西：测试。

很多做机器人的工程师写代码靠"跑一下看看"来验证。在仿真里跑一遍，轨迹没问题就算过了。这种做法在小项目里凑合能用，一旦代码量上去了、模块多起来了，bug藏在哪你根本不知道。

今天聊聊单元测试，重点讲Google Test在机器人项目中的实战应用。

Google Test基础：五分钟上手

Google Test（简称GTest）是C++领域最主流的测试框架，几乎是行业标准。ROS2的很多包内部就用的GTest。

#include <gtest/gtest.h>

int add(int a, int b) { return a + b; }

TEST(MathTest, AddPositive) {
    EXPECT_EQ(add(2, 3), 5);
}

TEST(MathTest, AddNegative) {
    EXPECT_EQ(add(-1, -2), -3);
}

EXPECT_EQ和ASSERT_EQ是最常用的两个断言宏。区别在于：EXPECT_EQ失败后继续执行后面的断言，ASSERT_EQ失败后直接退出当前测试用例。一般用EXPECT_EQ，除非后面的断言依赖前面必须成立的条件。

CMakeLists.txt里集成GTest也很简单：

find_package(GTest REQUIRED)
add_executable(math_test test_math.cpp)
target_link_libraries(math_test GTest::gtest_main)
gtest_discover_tests(math_test)

加上gtest_discover_tests之后，ctest命令就能自动发现并运行所有测试用例。CI里跑测试就一条命令的事。

机器人项目的测试策略

机器人代码和普通业务代码有个本质区别：它和硬件、时间、物理世界强耦合。电机转速依赖硬件反馈，SLAM依赖传感器数据流，控制循环依赖实时时钟。这些东西怎么做单元测试？

核心思路是隔离。把算法逻辑和硬件依赖剥离开，只测纯算法部分。

举个例子，你写了个PID控制器。PID的输入是目标值和当前反馈值，输出是控制量。这个计算过程是纯数学运算，不依赖任何硬件。直接构造输入、调用函数、检查输出，就是一个标准的单元测试。

TEST(PIDTest, ProportionalOnly) {
    PIDController pid(1.0, 0.0, 0.0);
    double output = pid.compute(10.0, 0.0, 0.01);
    EXPECT_NEAR(output, 10.0, 1e-6);
}

TEST(PIDTest, IntegralAccumulation) {
    PIDController pid(0.0, 1.0, 0.0);
    pid.compute(5.0, 0.0, 0.1);
    double output = pid.compute(5.0, 0.0, 0.1);
    EXPECT_NEAR(output, 10.0, 1e-6);
}

对于依赖硬件的模块，用Mock对象来替代。比如你的里程计模块需要读取编码器数据，测试时用Mock编码器返回预设值，验证里程计的计算逻辑是否正确。Google Mock（GMock）是GTest配套的mock框架，用起来很方便。

class MockEncoder : public EncoderInterface {
public:
    MOCK_METHOD(double, getVelocity, (), (override));
    MOCK_METHOD(int64_t, getTicks, (), (override));
};

TEST(OdometryTest, StraightLineMotion) {
    auto mock_enc = std::make_shared<MockEncoder>();
    EXPECT_CALL(*mock_enc, getVelocity())
        .WillRepeatedly(Return(1.0));
    Odometry odom(mock_enc, 0.1);  // wheel_radius=0.1
    odom.update(0.1);  // dt=0.1s
    EXPECT_NEAR(odom.getX(), 0.1, 1e-6);
}

数值计算的测试技巧

机器人领域大量涉及浮点运算，测试数值计算有个特殊问题：精度。两个理论上应该相等的浮点数，实际计算结果可能差个1e-10。用EXPECT_EQ直接比较肯定挂。

EXPECT_NEAR是解决方案——它允许你指定一个误差范围。但这个误差范围（tolerance）怎么定？定太大测不出问题，定太小频繁误报。

经验法则是：根据算法的数值稳定性来定。矩阵求逆、三角函数这类操作，tolerance一般设1e-6到1e-8。涉及大量累加的操作（比如积分），tolerance要放宽到1e-4。如果不确定，先跑一遍参考实现，看实际误差分布在哪里。

还有个技巧是相对误差。当数值本身很大的时候，绝对误差可能很大但相对误差很小。比如两个值都是10000量级，差0.001，绝对误差0.001看起来不小，相对误差才1e-7。这种情况下用相对误差判断更合理。

double expected = 10000.0;
double actual = 10000.001;
EXPECT_NEAR(actual / expected, 1.0, 1e-6);

参数化测试在数值计算中特别好用。你有一组输入输出数据，不想为每组写一个TEST，用TEST_P批量跑：

class KinematicsTest : public ::testing::TestWithParam<
    std::tuple<double, double, double>> {};

TEST_P(KinematicsTest, ForwardKinematics) {
    auto [j1, j2, expected_x] = GetParam();
    double x = forward_kin(j1, j2);
    EXPECT_NEAR(x, expected_x, 1e-4);
}

INSTANTIATE_TEST_SUITE_P(
    Arm2D, KinematicsTest,
    ::testing::Values(
        std::make_tuple(0.0, 0.0, 1.0),
        std::make_tuple(M_PI/2, 0.0, 0.0),
        std::make_tuple(0.0, M_PI/2, 0.5)
    ));