多库CMake项目如何合理组织GoogleTest单元测试目录结构

优先选方案A（各子库内嵌tests目录），这是适配中大型多组件生产项目的最优选择，方案B仅适合极小体量的短期项目。

选方案A的核心理由 #

• 维护边界完全对齐代码所有权
  改哪个库的代码，对应的测试就在同目录下，不用跨半层仓库翻根目录的测试文件夹找对应用例。开发改完代码顺手就能跑对应库的单测，PR评审时也能在同一个库的目录下直接对照代码变更和测试变更，不容易漏测。如果后续某一个库要拆出去做独立公共库、或者单独开源，直接拷贝整个库的目录就能带走全部源码和对应测试，不用额外从根目录零散扒测试文件。
• CMake配置更灵活，编译效率更高
  你可以给每个子库单独加编译开关，比如在LIB_A的CMakeLists里写option(BUILD_LIB_A_TESTS "Build unit tests for LIB_A" ${BUILD_ALL_TESTS})，开发时改了哪个库就只编译哪个库的测试，不用每次把全仓库几十上百个测试目标全编一遍，大项目里能省非常多编译等待时间。同时可以很方便做到正式发布编译Grand Library时，默认跳过所有测试目标的构建，完全不会把测试代码打进最终发布产物。
• 依赖隔离更清晰
  每个子库的测试只需要链接GTest和当前库本身、以及当前库明确声明的依赖，不会出现测试乱链接其他内部库的问题。比如LIB_A本来是无内部依赖的基础工具库，如果所有测试都堆在根目录，很容易写测试时不小心引用了LIB_B的函数，藏很久才发现隐式循环依赖，排查成本极高。

常见顾虑的解决方式 #

很多人倾向方案B是担心测试代码混在源码目录里“不干净”，这个问题完全可以通过构建配置解决：每个子库下的tests目录单独放CMakeLists.txt，只有当全局测试开关、对应子库的测试开关都打开时，才会被父级CMake引入构建，打包正式产物时直接排除所有tests目录即可，不会造成任何污染。

方案B的适用场景 #

如果你的项目总共只有2~3个强绑定的库，总代码量不足1万行，未来完全没有拆分独立库的计划，集中放根目录也能用。但只要项目规模继续扩张、组件数量超过5个，方案A的长期维护成本会远低于方案B。

补充优化建议 #

跨多个库的集成测试、端到端测试不要塞进单个子库的tests目录，可以在根目录单独建tests/integration目录存放，和各子库的单元测试分开管理即可，不影响整体组织逻辑。

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