Question

当使用Assert（...）时，如果逻辑测试失败，则单元测试将中止，并且不会运行其余的单元测试。有没有办法让逻辑测试失败，但只是提供警告或其他东西，仍然运行其余的单元测试？

上下文的一个例子是我有一个测试，创建一些学生，教师和类，创建关系，然后将它们放入数据库。然后在此数据库上运行一些SSIS包，这些包获取现有数据并将其转换为另一个数据库中的另一个数据库模式。然后，测试需要检查新数据库是否存在某些事情，例如正确的行数，操作等。

显然，其他测试是删除和修改，但它们都遵循相同的结构 - 在源数据库中创建数据，运行SSIS包，验证目标数据库中的数据。

Answer 1

听起来你试图在一次测试中测试太多东西。

如果不满足前提条件，那么大概测试的其余部分也不会通过。一旦我知道事情不符合我的预期，我宁愿结束测试。

单元测试的概念是Red fail，Green pass。我知道MSTest也允许黄色，但它不会做你想要的。你可以做一个Assert.Inconclusive来获得黄灯。当我在代码库上工作时，我已经使用过这个代码库，这个代码库有许多依赖于特定数据库数据的集成测试。我没有让测试失败，而是开始让结果无结果。代码可能工作正常，但数据丢失了。并且没有理由相信数据总是存在（他们不是IMO的好测试）。

Answer 2

根据您在问题中解释的内容，它更多的是验收测试（而不是单元测试）。单元测试框架旨在快速失败。这就是为什么Assert的行为方式（它是一件好事。）

回到你的问题：你应该看看使用像Fitnesse这样的验收测试框架，它可以支持你想要的东西，即告诉我失败的步骤但是继续执行到最后。
但是，如果必须使用单元测试框架，请使用收集变量/参数来模拟此行为。例如

在测试中保持List<string>
为每个失败的步骤附加描述性错误消息
在测试结束时，声明收集变量为空

Answer 3

如果您使用的是Gallio/MbUnit，则可以使用Assert.Multiple来实现您的目标。它捕获失败的断言，但不会立即停止执行测试。所有失败的断言都会在测试结束时收集并报告。

[Test]
public void MultipleAssertSample()
{
   Assert.Multiple(() =>
   {
      Assert.Fail("Boum!");
      Assert.Fail("Paf!");
      Assert.Fail("Crash!");
   });
}

上面例子中的测试显然是失败的，但有趣的是测试报告中显示了3个失败。执行不会在第一次失败时停止。

Answer 4

单元测试是黑白的 - 要么你通过测试，要么你是破坏逻辑，要么你的数据是否正确（尽管使用DB的单元测试不再是单元测试本身）。

你打算怎么处理这个警告？是通过还是失败？如果它通过那么在这种情况下单元测试的重点是什么？如果它失败了......那么......就失败了。

我建议花一点时间来确定应该进行单元测试的内容以及应该如何进行单元测试。 “单元测试”是许多用于非常不同的事情的陈词滥调。

Answer 5

当我想获得更有意义的故障报告时，我遇到了类似的问题。我在比较集合并习惯了错误的元素数量 - 不知道失败的真正原因是什么。不幸的是，我最终手动编写了一个比较代码 - 所以检查所有条件，然后在最后用一个好的错误消息做一个断言。

Answer 6

我知道您的问题是几年前提出的。但是最近（大约在2017年或2018年）NUNIT 3支持警告。您可以像声明Assert.Fail一样在Assert.Warning中嵌入[布尔]测试。但是，运行单一的测试不会记录整个测试失败，而是会记录警告并继续进行测试。

在此处阅读：https://github.com/nunit/docs/wiki/Warnings

它的行为类似于Multiple（上面由@Yann Trevin列出，并且Multiple在NUnit 3.0中也可用）。不过，最酷的区别在于集成测试，它具有使用独立Assert.Warning命令的灵活性。相对于在Multiple实例中的组断言。一旦完成多个断言，测试就可能不会继续。

集成测试，尤其是那些可以运行数小时才能进行的测试，也许测试一堆微服务都可以一起运行的性能，重新运行非常昂贵。另外，如果您碰巧拥有多个团队（外部，内部，外部，外部和内部），并且时区几乎始终在提交代码，那么要获得一个新产品来运行所有从头到尾的集成测试可能会很困难。一旦所有部分都托管在一起，就可以结束其工作流程。（注意-重要的是，组建具有丰富领域知识和至少足够软件工程知识的团队，以就每个API的形式组装可靠的“合同”并对其进行良好的管理。这样做应该有助于减轻上面暗示的不匹配。）

简单的黑白，通过/失败测试对于单元测试绝对正确。

但是，随着系统变得更加抽象，在服务之间，服务之间，代理之间分层，了解系统的鲁棒性和可靠性的能力变得越来越重要。我们已经知道一小段代码将按预期工作。单元测试和代码覆盖率告诉我们。但是当它们必须全部运行在其他人的基础架构（AWS，Azure，Google Cloud）之上时，单元测试还不够好。

知道服务必须重试多少次，服务成本是多少，给定某些负载，系统是否满足SLA？这些是集成测试可以帮助您使用所询问的断言类型@dnatoli的方法。

考虑到您提出问题的年限，您现在几乎可以肯定是专家。

Answer 7

单元测试可能比集成测试更非黑即白，但如果您使用的是像 spek flow 这样的工具，那么您可能需要测试框架来给您一个警告或断言不确定...

为什么有些单元测试框架允许你断言非黑即白的不确定？

想象一下，您在单元测试中传递的测试日期是从随机数据生成器创建的...也许您有几个...对于某些数据条件，您确定它是失败的另一天来调整你可能不确定......

警告或某些不确定的要点是告诉工程师看看这个极端情况并添加更多代码以尝试下次捕获它...

假设你的测试永远是完美的或黑白的我认为这是不正确的我遇到了太多的案例和 15 年的测试，它没有通过或失败......它通过了......失败了......我还不知道......你必须考虑这样一个事实，当你失败时，这意味着你知道它失败了......

在自动化测试中，错误的失败真的很糟糕......它会产生很多噪音......你最好说我不知道如果你不知道你正在失败......

C＃单元测试警告而不是失败

7 个答案: