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