我刚刚开始使用TDD，并且很好奇其他人如何运行测试。作为参考，我使用的是谷歌测试框架，但我相信这个问题适用于大多数其他测试框架和C/C++以外的语言。你如何运行你的单元测试？编译器标志？静态库？
我一般的做法至今一直做的三两件事之一：
写的大部分应用程序的静态库，然后再创建两个可执行文件。一个可执行文件是应用程序本身，而另一个则是所有测试的测试运行器。都链接到静态库。
嵌入测试代码直接插入应用程序本身，以及启用或使用编译器标记禁用测试代码。这可能是迄今为止我使用过的最好的方法，但会使代码混乱一点。
嵌入给出的测试代码直接插入应用程序本身，而且，某些命令行切换某一种运行该应用程序本身或运行嵌入在应用程序中的测试。
这些解决方案都不是特别优雅 ...
如何你办呢？
我倾向于倾向于使用dll的静态库，所以我的大部分C++代码都会以静态库的形式结束，正如您发现的，它们与dll一样容易测试。
对于构建到exe中的代码，我要么有一个单独的测试项目，它只包含测试中的源文件，这些文件通常内置在exe中，或者构建一个新的静态库，其中包含大部分exe文件，按照我测试所有其他静态库的方式来测试。当我对现有应用程序进行复古适配测试时，我发现我通常采用新项目中的'大部分代码库'方法和'将exe项目中的源文件拖入测试项目'方法。
我不喜欢你的选项2和3。管理2的构建配置可能比拥有一个单独的测试项目更加困难，该项目只需将它需要的源文件拖入其中，并将所有测试包括到exe中，如您在第3章中所建议的那样错误;）
我在他们的框架中使用第三方测试运行者，并在构建脚本中包含测试。测试不在生产代码（外部DLL）之外。
什么框架？此外，这并不能解释测试如何访问您的应用程序代码。这是黑匣子还是系统测试？ – kurige 2010-04-21 07:30:21
主要是，我使用.net进行开发，所以无论是NUnit（如果项目无法承受测试suppost的Visual Studio）或MS单元测试框架。我听说过有关向MS单元添加C++支持的一些信息，但不确定。 问题的第二部分：是的，这是黑匣子测试。 – 2010-04-21 08:04:04
您的方法没有。 1是我总是用C/C++和Java完成的。大多数应用程序代码位于静态库中，我尽量将应用程序所需的额外代码量降至最低。
我在Python等动态语言接近TDD的方式是在稍有不同，我离开的源代码的应用程序和测试躺在身边和测试运行发现测试和运行它们。
我使用了两种方法，对于dll我只是将我的单元测试与dll链接起来，很简单。对于可执行文件，我包括可执行项目和单元测试项目中正在测试的源文件。这稍微增加了构建时间，但意味着我不需要将可执行文件分离为静态库和主函数。
我使用boost.test进行单元测试和cmake生成我的项目文件，我觉得这是最简单的方法。此外，我正在慢慢地将单元测试引入一个大型的遗留代码库，所以我正在尝试引入最少量的更改，以防其他开发人员带来不便，并阻止他们进行单元测试。我担心只为单元测试使用静态库可能被视为不采用它的借口。
话虽如此，我认为静态库的方法是一个很好的，特别是如果你从头开始。
我喜欢简单地重新编译相关源文件的想法，但你是正确的，它确实增加了相当多的时间来构建。 对于较大的项目，这将是不切实际的。 – kurige 2010-04-23 10:19:58
对于C/C++应用我尝试有尽可能多的代码尽可能在一个或多个DLL，与主应用程序是最低限度的，以启动和越区切换到该DLL。 Dll测试起来要容易得多，因为它们可以输出尽可能多的入口点，以便让测试应用程序使用。
我使用一个单独的测试应用程序链接到Dll（s）。我强烈支持将测试代码和“产品”代码保存在不同的模块中。
我去＃1，部分原因是
对于C++构建和测试，我喜欢使用CMake，它可以运行一系列目标可执行文件作为测试并打印结果摘要。
Personnally，I use另一种依赖于你的方法：
我保持项目对测试不变。如果它是可执行文件，它应该保持可执行文件。您只需创建后期构建操作即可将所有obj文件聚合到静态库中。
然后，您可以创建测试项目，将测试框架和以前生成的静态库链接起来。
下面是对应你的问题的一些主题：
的共识似乎是，＃1是最好的。这似乎并不像它可能那样优雅。我想如果我想要优雅，我应该改用脚本语言。 ：p – kurige 2010-04-23 10:17:00