也许我没有正确地思考这个问题。 我正在使用单元测试开始我的第二个项目。我的第一个项目是我自己编写的,对于这个项目,我正在尝试Boost :: test。
我的问题是,编译成可执行文件的单元测试项目的正确程序是什么?似乎我看到的所有东西都是库和依赖项。我希望我的exe项目经过单元测试,但我不希望在二进制文件中出现一堆单元测试函数,我也不想这样做
#ifdef _DEBUG
BOOST_AUTO_TEST_CASE( my_func )
{
}
#endif
围绕我的所有测试。
我考虑过为单元测试创建一个单独的项目,但这并不适用于可执行文件..除非我想做一些花哨的预构建操作从我的其他项目复制到测试项目中..
有什么想法或想法吗?
答案 0 :(得分:7)
该项目可以编译为一个库,这个库可能静态地链接在两个独立的可执行文件中:“项目”,将交付,以及单元测试。
现在问题似乎来自你的IDE,它是哪一个?是否允许为一个项目创建两个二进制文件?
答案 1 :(得分:6)
我使用 cppunit 在一个额外项目中测试我的可执行文件,该项目只链接到从可执行代码生成的* .obj文件。这样,您在原始代码库中就没有任何测试逻辑,并且可以为您的测试编写单独的控制台或Windows应用程序。
干杯 霍尔格
答案 2 :(得分:3)
我们的想法是创建一个单独的项目,在这个项目中,无论是否构建调试,都会测试预期行为的单独单元代码(某些问题甚至不会出现在调试版本中)代码差异) 您将其构建为二进制文件并运行以查看您的更改是否没有破坏任何内容 - 通常甚至将其设置为自动构建后操作。
如果您想从外部测试您的应用程序 - 可能有一些测试框架可供您使用,具体取决于区域/框架/等。应用程序...但Boost.Test和所有其他单元测试框架不用于测试可执行文件。
答案 3 :(得分:2)
您可以从单元测试项目中包含必要的.cpp文件并进行测试。
正如我所做的那样:
测试\游戏服务器\ PVESettingsTest.cpp:
#include "../../sources/GameServer/PVESettings.cpp"
一切正常......
答案 4 :(得分:1)
对可执行文件进行单元测试可能是一个好主意 - 但要意识到它与单元测试代码完全不同。一旦有了可执行文件,就不再有C ++或Boost了。这只是一个程序。您需要能够以不同的机制运行它并分析/控制输入:
输入:
stdin
输出:
stdout
在shell中运行它可能最容易。 bash
将在Linux环境中运行奇迹(管道传入/传出文件,在输出上运行sed
/ awk
/ grep
以分析正确性)。您可以使用Perl或Python以及它们各自的单元测试框架,需要注意的是您必须将程序的调用包装在其他函数中:两种语言都支持来自子进程的管道概念,python使用{{1} }模块和Perl及其标准的文件打开机制。
无论你做什么,你都 想要尝试从C ++对整个可执行文件进行单元测试。