如何在不修改生产代码前提下对MISRA要求的static配置类对象做单元测试

可行测试方案如下： #

• 方案1：调整测试构建链路，通过符号导出获取实例访问权
  不需要修改生产环境的objects.cpp文件，仅在测试构建流程中做特殊处理：测试构建时不直接使用生产编译生成的objects.o，而是通过构建脚本临时对objects.cpp做无侵入修改，比如在文件末尾追加一行导出实例的代码：

  dog& test_access_my_dog() { return my_dog; }
  

  测试构建完成后即可丢弃临时修改的文件，完全不会污染生产代码仓库。如果不想修改文件内容，也可以单独写一个测试专用的编译单元，复用原objects.cpp中的配置逻辑，将static修饰符临时替换为外部链接属性，和其他测试依赖一起链接即可。
  该方案的优势是完全不侵入生产代码，也不需要调整现有生产构建逻辑，仅需修改测试侧的构建脚本即可实现，同时支持多实例场景下的批量导出。

• 方案2：基于公开接口做黑盒行为验证
  如果你完全不想触及实例的访问权限，直接通过类的公开行为接口验证配置和交互逻辑即可：

  1. 验证配置正确性：调用dog类对外暴露的功能接口，比如触发吠叫的接口，校验输出的音量、频率等参数是否和预期配置一致，即可反向验证配置生效逻辑正确。
  2. 验证跨对象交互：模拟newspaper等关联对象的触发条件，检查my_dog的行为反馈是否符合预期，即可完成集成层级的测试。
     该方案不需要对生产代码、生产构建、测试构建做任何修改，完全基于现有公开接口即可实现，适合做端到端的功能验证。

• 方案3：添加无侵入的条件编译导出逻辑
  如果可以接受对objects.cpp做不影响生产构建的极小改动，可以在文件末尾追加条件编译块：

  #ifdef UNIT_TEST
  dog& test_get_my_dog() {
      return my_dog;
  }
  #endif
  

  生产构建时不会定义UNIT_TEST宏，这段代码不会被编译到生产程序中，完全不影响MISRA合规性和生产逻辑；测试构建时定义该宏即可直接获取my_dog的引用，进行各类白盒测试，多实例场景下只需追加对应导出函数即可。

内容的提问来源于stack exchange，提问作者Michael