我刚刚开始使用 TDD，并且很好奇其他人采用什么方法来运行他们的测试。作为参考，我使用的是谷歌测试框架，但我相信这个问题适用于大多数其他测试框架和 C/C++ 以外的语言。
到目前为止，我的一般方法是做以下三件事之一：
在静态库中编写大部分应用程序，然后创建两个可执行文件。一个可执行文件是应用程序本身，而另一个是包含所有测试的测试运行程序。两者都链接到静态库。
将测试代码直接嵌入应用程序本身，并使用编译器标志启用或禁用测试代码。这可能是我迄今为止使用过的最好的方法，但会使代码有点混乱。
将测试代码直接嵌入到应用程序本身中，并且，给定某些命令行开关，要么运行应用程序本身，要么运行嵌入在应用程序中的测试。
这些解决方案都不是特别优雅......
你是怎么做到的？
你的方法没有。1 是我一直使用 C/C++ 和 Java 的方式。大多数应用程序代码都在静态库中，我尽量将应用程序所需的额外代码量保持在最低限度。
我在 Python 和其他动态语言中处理 TDD 的方式略有不同，因为我将应用程序和测试的源代码留在周围，而测试运行程序会找到并运行它们。
对于 C/C++ 应用程序，我尝试在一个或多个 dll 中包含尽可能多的代码，而主应用程序是启动和移交给 dll 的最低限度。Dll 更容易测试，因为它们可以导出任意数量的入口点供测试应用程序使用。
我使用链接到 Dll(s) 的单独测试应用程序。我强烈赞成将测试代码和“产品”代码保存在单独的模块中。
我倾向于使用静态库而不是 dll，因此我的大多数 C++ 代码最终都以静态库结尾，并且正如您所发现的，它们与 dll 一样容易测试。
对于构建到 exe 中的代码，我要么有一个单独的测试项目，它只包含正在测试的源文件并且通常内置在 exe 中，要么我构建一个包含大部分 exe 的新静态库并在与我测试所有其他静态库的方式相同。我发现我通常在新项目中采用“库中代码最多”的方法，当我对现有应用程序进行改装测试时，我通常采用“将源文件从 exe 项目拉入测试项目”的方法。
我根本不喜欢你的选项 2 和 3。管理 2 的构建配置可能比拥有一个单独的测试项目更难，该项目只是简单地提取它需要的源并将所有测试包含在 exe 中，正如你在 3 中建议的那样，这是错误的；）
我使用两种方法，对于 dll，我只是将单元测试与 dll 链接起来，很简单。对于可执行文件，我包括在可执行项目和单元测试项目中正在测试的源文件。这会稍微增加构建时间，但意味着我不需要将可执行文件分离到静态库和主函数中。
我使用 boost.test 进行单元测试并使用 cmake 生成我的项目文件，我发现这是最简单的方法。此外，我正在慢慢地将单元测试引入大型遗留代码库，因此我试图引入最少的更改，以防我给其他开发人员带来不便并阻止他们进行单元测试。我担心将静态库仅用于单元测试可能会被视为不采用它的借口。
话虽如此，我认为静态库方法是一种不错的方法，特别是如果您从头开始。
我选择#1，一些原因是
对于 C++ 构建和测试，我喜欢使用 CMake，它可以运行选择的目标可执行文件作为测试并打印结果摘要。
就个人而言，我使用另一种方法，它有点依赖于你的方法：
我保持项目测试完好无损。如果它是一个可执行文件，它应该是一个可执行文件。您只需创建一个构建后操作，以便将所有 obj 文件聚合到一个静态库中。
然后，您可以创建您的测试项目，链接测试框架和您之前生成的静态库。
以下是与您的问题相对应的一些主题：
我正在使用第三方测试运行程序及其框架，并在构建脚本中进行测试。测试在生产代码（外部 dll）之外。