延迟的 NUnit 断言消息评估答案

【问题标题】：Delayed NUnit Assert message evaluation延迟的 NUnit 断言消息评估
【发布时间】：2013-01-14 13:34:32
【问题描述】：

我的测试代码中有这个断言

Assert.That(() => eventData.Count == 0,
Is.True.After(notificationPollingDelay),
"Received unexpected event with last event data" + eventData.Last().Description());

在一段时间后断言某些条件并且在失败时会产生一条消息。它无法运行，因为消息字符串是在断言开始时构造的，而不是在断言结束时构造的。因此eventData 集合仍然是空的（因为它最初是空的）并且尝试获取集合中最后一项的Description 失败。 NUnit 中是否有解决方法或体面的替代方法，或者我是否必须在测试中恢复使用 Thread.Sleep？

PS：我使用的是 NUnit 2.5.10。

【问题讨论】：

据我所知，这不是原生 NUnit 断言语法。您使用的是哪个断言库？
@DanielHilgarth - 当使用基于约束的模型时，这是有效的 NUnit 断言语法。 After 是延迟约束 nunit.org/index.php?p=delayedConstraint&r=2.6.2
@manojlds：感谢您提供的信息。对于任何感兴趣的人：DelayedConstraint 与 EqualConstraint 结合使用 constrained-based assert module。
我觉得你运气不好。根据我在上一条评论中链接到的文档，没有过载可以接受委托在以后创建消息。
Nnnnoooooooooooooooo卢克的声音>

标签： c# nunit

【解决方案1】：

你可以使用这个方案：

var constrain = Is.True.After(notificationPollingDelay);
var condition = constrain.Matches(() => eventData.Count == 0);
Assert.IsTrue(condition, 
              "Received unexpected event with last event data" + 
              eventData.Last().Description());

这个方法类似于使用Thread.Sleep

【讨论】：

我喜欢您将代码拆分成这些逻辑步骤的方式。我现在没有方便的编译器来检查结果，第二行（建立条件）是等待发生的地方吗？如果是这样，我想这是迄今为止最好的解决方法..
在var condition = constrain.Matches(() => eventData.Count == 0); 中发生挂起。在我编写这段代码时检查了编译器:)

【解决方案2】：

在 NUnit 3.50 版中，我不得不使用不同的语法。示例如下：

var constraint = Is.True.After( delayInMilliseconds: 100000, pollingInterval: 100);
Assert.That( () => yourCondition, constraint );

这将使用Is.True.After 方法创建的DelayedConstraint 来测试yourCondition 是否为真的等待某个最长时间。

在此示例中，DelayedConstraint 配置为使用 100 秒的最长轮询时间，每 0.1 秒轮询一次。

另请参阅DelayedConstraint 的旧版 NUnit 2.5 文档。

【讨论】：

【解决方案3】：

最简单的答案是“不要在失败消息中包含该文本”。我个人几乎从不包含失败信息；如果您的测试足够原子，则不需要这样做。通常，如果我需要找出一个神秘的故障，无论如何只有调试器会有所帮助。

如果你真的想这样做，这段代码应该可以在不自己管理线程的情况下工作。

try
{
    Assert.That(() => eventData.Count == 0, Is.True.After(notificationPollingDelay));
}
catch(AssertionException)
{
    throw new Exception("Received unexpected event with last event data" + eventData.Last().Description());
}

【讨论】：

don't include that text in your failure message - 你给出一个建议并破坏了测试中最重要的事情之一 - 尝试 catch。尤其是一个断言。 -1