使用Google Test编写的C++单元测试代码会随项目一同导出吗？相关最佳实践是什么？

Great question—this is a super common concern when setting up unit tests with Google Test, and it’s totally valid to want to keep your production build lean. Let’s break this down clearly:

1. 单元测试代码会自动随项目编译导出吗？ #

默认不会——只要你项目结构和构建配置合理。如果不小心把测试代码和生产代码放在同一个编译目标（比如同一个可执行文件或库）里，那它们确实会一起编译。但这是错误的做法，正规的项目都会把测试代码和生产代码做严格隔离。

举个例子：如果你的生产代码在src/目录，测试代码单独放在tests/目录，并且通过构建工具（比如CMake、Makefile）分别配置生产目标和测试目标，那么编译生产版本时，构建工具只会处理src/里的代码，完全不会碰tests/的内容。

2. 需要手动删除测试代码吗？ #

完全不需要！手动删除不仅麻烦，还会导致你下次要跑测试时得重新找回代码，得不偿失。只要做好隔离，测试代码会一直留在你的代码仓库里，但永远不会被编译到生产产物中。

3. 单元测试与项目导出的通用最佳实践 #

这里有几个行业通用的做法，能帮你彻底解决这个问题：

• 物理隔离测试文件：把所有测试代码放到单独的目录（比如tests/或test/），和生产代码的src/、include/目录完全分开。这样从结构上就避免了混淆。
• 构建系统层面隔离目标：
  • 用CMake的话，给生产代码创建一个目标（比如add_executable(my_app src/main.cpp src/utils.cpp)），给测试代码单独创建另一个目标（add_executable(my_app_tests tests/test_utils.cpp tests/test_main.cpp)），并让测试目标依赖生产代码和Google Test库。编译生产版本时，只执行cmake --build . --target my_app即可。
  • 用Makefile的话，写单独的test规则，生产构建只执行默认的all规则，不包含测试目标。
• 避免在生产代码中嵌入测试逻辑：不要用#ifdef之类的宏把测试代码混在生产文件里（除非万不得已），物理隔离是最清晰、最不容易出错的方式。
• CI/CD流程分离测试与部署：在持续集成中自动运行测试，但部署环节只打包生产构建的产物（比如编译好的可执行文件、库），测试代码和测试可执行文件不会被包含在部署包中。

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