机器人测试

要解决的问题

机器人软件的测试比普通服务难在三处：节点之间靠 DDS 通信，状态分散在多个进程里；真实硬件和仿真环境行为不一致；CI 里跑一次完整 launch 可能要几分钟，很容易写出"本地能过、流水线随机挂"的 flaky 测试。结果就是团队要么不写测试，要么写一堆只在开发者机器上有效的用例。

技能如何工作

这个技能围绕机器人测试金字塔组织能力，覆盖从单元到集成的各层：

• 单元测试：为 ROS1/ROS2 节点编写测试，推荐用 pytest 配合 rclpy 的节点 API。技能给出了典型的 fixture 写法：ros_context 以 module 作用域初始化 rclpy.init() / rclpy.shutdown()，避免每个测试都重复起停节点；perception_node 每个测试新建一个干净节点，测试结束调用 destroy_node()。
• 测试数据构造：不依赖真实传感器，用 numpy 直接造 sensor_msgs/Image 这类合成消息（设定 height、width、encoding、step 和 data），让感知流水线在无硬件时也能跑。
• 集成测试：基于 launch_testing 验证多个节点协同启动和通信的情况。
• 硬件隔离：Mock 传感器和执行器，让 CI/CD 不依赖实体硬件。
• 仿真与真值验证：搭建基于仿真的测试套件，用 ground truth 检验感知流水线的输出；对轨迹规划器和控制器做结果校验。
• CI/CD 与排障：为机器人包配置流水线，并针对机器人系统中常见的 flaky 测试做定位和修复。

适用边界与注意点

• 技能聚焦"怎么写测试"，不负责实现节点逻辑本身。
• Mock 得再好也不等于真机行为，落地前建议保留一层仿真和真机回归用例。
• fixture 的作用域选择要谨慎：module 级共享上下文能省时间，但如果测试间有参数污染，要降为 function 级。
• 本仓库资料对具体命令和参数有截断，实际接入时需对照完整的 SKILL.md 确认细节。