我有一些问题涉及从assert.h测试包含断言宏的一些函数的事实。
如果断言失败，测试也会失败。 这给我留下了一些永远不会起作用的测试用例。
例如，一个函数而不是指示失败（返回false或类似的东西）断言。
是否有解决方案（包含断言的单元测试函数）？
答案 0 :(得分：12)
你可能正在测试这个断言在你期望它时中止的事实（在错误的输入上）。
测试框架Google Test作为ASSERT_DEATH宏，将测试程序是否在中止的位置（如断言）。
您也可以使用NDEBUG定义（-DNDEBUG with gcc）来禁用单元测试的断言。
答案 1 :(得分：9)
也许只是我，但我认为如果你有断言失败，你甚至不应该考虑更高级别的单元测试，直到你修复它们为止。我们的想法是，如果代码写得正确，断言在任何情况下都应该永远不会失败，包括单元测试。或者至少我是如何编写代码的。
答案 2 :(得分：7)
不，单元测试就是您在开发过程中所做的。断言是一个运行时构造。
根据我的经验，大部分时间断言都是在生产中关闭的。但你应该一直在测试。
CppUnit是一个很好的测试框架。它是C ++的nUnit系列的一部分。
答案 3 :(得分：2)
在任何情况下，断言都不应该失败。如果它们在测试中失败，则表示存在逻辑错误。基本上，如果你的函数正在执行“assert（0）”而不是返回错误代码，那么应该重写该函数。如果中止是所需的行为，则exit（）是合适的，但不是assert（）。
如果在测试期间断言失败，则代码出错并且必须更改。代码“assert（x）”应解释为“程序的逻辑要求x为真。在任何情况下都不能是假的。”如果您的单元测试导致断言失败，则该语句显然无效并且必须进行修改。
答案 4 :(得分：1)
基本上听起来你的测试框架并不是为了测试你的断言而构建的。
如果断言将暂停进程，则需要一些能够监视执行状态的内容。
boost-test如何执行此操作的示例： http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/prg_exec_monitor/index.html
我在一段时间内没有做过C或C ++编码，但是，我会从类似的技术开始。