我的问题与something asked before非常相关，但我需要一些实用建议。将单元测试添加到现有项目
我的手中有“有效地使用遗留代码”，我正在使用我正在编写的项目中阅读的书中的建议。该项目是一个由几个库组成的C++应用程序，但代码的主要部分被编译为单个可执行文件。当我必须触摸某些东西时，我正在使用googletest向现有代码添加单元测试。
我的问题是如何设置我的构建过程，所以我可以建立我的单元测试，因为有需要，而我无法从我的“测试”应用到提取代码共享代码的两个不同的可执行文件图书馆。现在我已经为应用程序构建了我的构建过程，该过程持有单元测试链接，与主应用程序的构建过程生成的对象文件相对照，但我真的不喜欢它。有什么建议吗？
一个唯一的开发商如果您的测试版应用程式仅链接对象需要测试的文件，那么你实际上已经将它们视为一个库，应该可以将这些目标文件分组到一个单独的库中，以供主应用程序和测试应用程序使用。如果你不能，那么我就不会看到你正在做的事情太糟糕了。
如果您不得不链接其他未经测试的对象文件，那么这是一个需要打破的依赖关系的标志，为此您有完美的书。 我们有类似的问题，并使用一个像Vlion建议的系统
Working Effectively With Legacy Code是如何开始测试旧代码的最佳资源。真的没有短期的解决方案，不会导致情况变得更糟。
我个人会继续按照您的操作进行操作，或者考虑让构建脚本同时生成目标应用程序和单元测试（两个生成的二进制文件脱离相同的代码库）。是的，它闻起来很腥，但很实用。
荣誉给你，祝你的测试顺利。
我更喜欢每个测试一个测试可执行文件。这样可以实现链接时间接缝，并且还可以帮助允许使用TDD，因为您可以在一个单元上工作，而不用担心其他代码。
我让库取决于所有的测试。希望这意味着你的测试只能在代码实际改变时运行。
如果确实发生故障，测试会在正确的位置中断生成过程。
我就勾勒出一个makefile结构，你可以使用：
all: tests executables
run-tests: tests
<commands to run the test suite>
executables: <file list>
<commands to build the files>
tests: unit-test1 unit-test2 etc
unit-test1: ,files that are required for your unit-test1>
<commands to build unit-test1>
这大致就是我做的，因为我的项目
为什么投票？ – 2009-03-04 19:43:11