我有 63 个 DLL，每个都有各种 C++ 方法。我想验证一些具有固定输入值的方法的输出。我想知道在编译构建过程中是否可以在 DLL 本身中进行单元测试。
因此，DLL 的编译构建在 Visual Studio 的输出窗口中给出了单元测试的结果。
我知道我可以通过创建可执行文件并调用方法来验证这种情况。但是，没有可执行文件可以吗？
问问题
1426 次
4 回答
2
您必须等待编译完成，以便代码中没有编译错误。
在构建后事件中，您可以添加批处理文件，这些文件将运行您的单元测试模块并验证编译后生成的二进制文件。
于 2013-05-05T18:48:34.657 回答
2
逐字逐句回答您的问题，答案是“否”，因为您甚至还没有完成编译 DLL 时无法测试它。此外，您需要某种可执行文件来加载该 DLL，因此您可以使用脚本语言（想到带有 ctypes 的 Python）加载它，或者创建一个可执行文件。
正如 shivakumar 所建议的，从 Visual Studio 中的后编译步骤调用它可能是将结果输入输出窗口的唯一方法。我个人更喜欢从外部构建脚本运行它，但我也进行了很多交叉编译，我无法从那里的后编译步骤运行东西。这也使得在出现故障时更容易调试单元测试。
于 2013-05-05T19:54:27.300 回答
2
正如其他人所说 - “在编译期间”测试没有意义，所以我假设你的意思是在构建过程中进行测试，这是不同的，当然可以使用构建后步骤等。
您没有指定使用哪个版本的 Visual Studio，但如果您有 VS2012，则有一篇MSDN 文章准确描述了如何执行您所描述的操作。有关完整说明，请参阅链接，我在下面附上了部分屏幕截图
于 2013-05-06T08:29:54.750 回答
2
你在要求一件没有意义的事情。当您说“编译”时，这意味着非常具体的事情：在调用链接器之前调用编译器。但是 C++ 代码（和 C++ 单元测试）不能那样工作。编译器必须完成对生产代码和测试的编译，然后必须将目标文件链接到库、可执行文件或两者中。然后，测试框架必须执行调用您的生产代码的测试代码才能获得结果。这些步骤在 C++ 中都不是可选的。
相反，您可能想问是否可以将单元测试作为构建的一部分（而不是编译）运行。答案是明确的“是的！”
我猜您的解决方案可能包含 63 个或更多单独的 DLL 项目。对于您要测试的每个生产 DLL，例如 Foo.DLL，我建议您添加一个新的 FooTest 项目，并将单元测试代码添加到 FooTest 项目中。在 FooTest 中，在 Foo 项目上创建一个项目依赖项，这将强制 FooTest 在构建 Foo 之后构建。在 FooTest 项目中，您将有两种代码模块：包含单元测试的类，以及 FooTest.cpp，它将容纳 FooTest.EXE 程序的 main() 入口点，调用测试框架并将结果输出到安慰。
创建您的 FooTest.cpp，使其成为控制台程序。如果您格式化测试可执行文件的输出，使其与 Visual Studio 编译器的输出相匹配，如“filename.cpp(lineNo) : error: description of failure”，则 Visual Studio 将在您单击时自动导航到文件和行它。诸如 CppUnit 之类的单元测试框架可能已经有一个“CompilerOutputter”类，它可以正确格式化输出以匹配编译器的错误。
在您的 FooTest 项目中，您还需要将输入设置为 FooTest 链接器，以便它可以链接到您尝试测试的生产代码中。在 FooTest 项目的属性中，转到 Linker/Input 选项卡并将 Foo 项目的 OBJ 文件的路径添加到 Additional Dependencies。我使用的行如下所示： $(SolutionDir)Foo\Debug\obj*.obj
在 FooTest 项目的 Build Events 属性中，调用新的 FooTest.EXE 作为构建后步骤。然后，每次单击构建时，都会构建代码并执行单元测试。项目依赖项将确保如果您更改 Foo 代码，您将编译、链接和执行 FooTest 测试。控制台输出可确保您的测试结果在 IDE 中显示为可点击的输出。
您可以创建 63 个单独的单元测试可执行文件，或者您可以创建一个包罗万象的单元测试可执行文件。这完全是你的选择。如果您希望更快地进行构建和链接，您可能希望拥有单独的可执行文件；即使它是更多的个人配置工作，您也只需执行一次，之后您就可以保留快速构建以进行小幅更改的好处。
现在你已经准备好进行一些严肃的编码了。
于 2013-05-06T22:53:00.560 回答