正如本文Exception vs Assert? 中提到的，异常用于运行时错误条件，而断言用于编码错误。
据我所知，单元测试用于验证函数的功能。除了我们已经知道结果的合法测试用例之外，是否还要在unit-test中编写一些非法的测试用例来测试是否发生了断言或者是否抛出了异常？
【问题讨论】：
assert 出现编码错误，您应该无法“启动”它们（如果可以的话，无论如何都会是 UB）。
标签： c++ function unit-testing exception assert
您的问题无法笼统地回答。
完美的单元测试是不可能的，即使是“非常好”的单元测试也非常困难，只有在测试“非常好”的代码时才有可能。小心不要掉入这个陷阱，一切看你的质量要求。
当失败可能导致生命损失时，您是否开发了关键任务系统？加倍努力并尽可能多地进行测试。无论如何，任何改变都必须经过许多官僚步骤。否则适应您的要求。自动化测试的主要好处之一是简化重构，当您可以更改（有时是显着的）您的实现并仍然确保它在某种程度上有效时。太多的测试和这把枪指向你，因为任何更改都需要在测试中进行大量更改，最终阻碍你的进步。
像往常一样没有灵丹妙药
【讨论】：
你可以。当“坏”场景发生时，测试断言和/或异常是否发生是一个好主意。
阅读更多：
PS：你必须这样做吗？嗯，这取决于你的项目。
【讨论】：
问问自己：是异常代码还是断言代码？为什么要编写异常和断言？他们有功能！应该保护您的代码免受例如来自“外部”的意外数据。因此，如果您需要这种保护，则必须检查代码的功能。
如果您不检查代码会发生什么： 也许您检查异常的范围是错误的，并且您在未预料到的情况下抛出，或者您没有抛出但您的执行现在以未定义的行为运行。
我的观点很简单：您编写代码，异常和断言就是代码。代码做了一些有用的事情，所以你必须检查它。从逻辑的角度来看，断言和异常与 if/the/else 错误处理没有区别。要获得完整的调用树检查，您必须检查它。 c++ 具有特殊的语言特性并不意味着这会导致不检查使用该特性的代码部分。
【讨论】：
您还应该测试错误情况，以确保被测试的方法正确处理错误（例如，该方法真的抛出异常还是只是在压力下发生段错误？）。
如果您使用 gtest，那么您可以使用 EXPECT_THROW 或 ASSERT_THROW 测试是否引发了特定异常。
【讨论】：