基于CMake的共享库内部功能测试构建系统设计技巧及方案对比

方案1：为测试单独编译带符号暴露的库变体 #

• 实现方式：保留主库的符号隐藏规则不变，新增一个专门供测试用的库目标（比如在CMake里定义mylib_test），该目标共享主库的源码，但启用不同的编译选项——比如全局设置-fvisibility=default，或者针对需要测试的源码文件单独开启符号可见性。测试可执行文件链接这个测试专用库，而非生产版本的库。
• 权衡：
  • 优点：生产版本的符号隐藏策略不受影响，不会出现意外暴露的符号；可以精准控制测试版库的符号范围，避免全量暴露。
  • 缺点：需要维护额外的CMake配置和编译目标，整体编译时间会增加；如果内部符号依赖链复杂，可能需要调整多个文件的编译选项，配置成本略高。

方案2：使用测试专用的条件导出宏 #

• 实现方式：定义一个全局宏（比如MYLIB_TEST_API），默认状态下标记符号为隐藏，当开启测试时改为标记为可见。在需要测试的内部函数、类前添加这个宏：

  #ifdef BUILD_TESTING
  #define MYLIB_TEST_API __attribute__((visibility("default")))
  #else
  #define MYLIB_TEST_API __attribute__((visibility("hidden")))
  #endif
  
  // 内部测试目标函数
  MYLIB_TEST_API void internal_calculate(int param);
  

• 权衡：
  • 优点：精准控制单个内部符号的可见性，不会全量暴露所有符号；生产代码的符号规则保持严格，仅针对测试场景放开必要符号。
  • 缺点：需要手动给所有待测试的内部符号添加宏标记，对现有代码有一定侵入性；如果待测试内部符号数量多，修改成本较高。

方案3：通过链接器配置控制符号导出（平台相关） #

• 实现方式：利用平台链接器的符号控制功能，比如Linux下用链接器脚本，Windows下用.def文件，macOS下用-exported_symbols_list参数。主库默认使用隐藏符号的配置，测试时切换为包含待测试内部符号的导出配置。在CMake中可以通过CMAKE_SHARED_LINKER_FLAGS变量切换不同的链接配置文件。
• 权衡：
  • 优点：无需修改源码，完全通过编译链接配置实现符号控制，对代码无侵入；可以精准指定要导出的符号，不影响主库的默认符号隐藏策略。
  • 缺点：平台依赖性强，不同操作系统的配置语法差异大，需要维护多套配置；对链接器配置的语法需要一定了解，调试问题时门槛较高。

方案4：将测试逻辑嵌入共享库内部 #

• 实现方式：把单元测试代码作为共享库的条件编译部分，当开启测试时，编译并暴露一个测试入口函数，测试可执行文件只需调用这个入口，无需直接访问内部符号。示例代码：

  #ifdef BUILD_TESTING
  #include "internal_tests.h"
  #include <gtest/gtest.h>
  
  extern "C" __attribute__((visibility("default"))) void run_internal_tests() {
      testing::InitGoogleTest();
      RUN_ALL_TESTS();
  }
  #endif
  

• 权衡：
  • 优点：完全不需要暴露内部符号给外部，测试逻辑在库内部执行，安全性最高；无需额外编译库变体，编译成本低。
  • 缺点：测试代码与生产代码耦合，即使是条件编译也会增加库的代码体积；测试灵活性受限，部分外部测试框架的特性可能需要额外适配才能使用。

内容的提问来源于stack exchange，提问作者Кирилл Волков