Question

我们的内部框架使用通用类 DBField<T> 来模拟具有与实体框架不兼容的数据库（例如 Oracle 11 或 Sybase）的实体字段。

我们试图让它尽可能透明（同样，就像实体字段一样），以便以下代码工作：

    DBField<int?> z_intLength = 2;
    while (z_intLength <= 5)
    {
        z_intLength++;
    }

    //[...]

    DBField<int?> z_intMaxLength = 10;
    if (z_intLength > z_intMaxLength)
    {
    }

上面的效果很好。我们使用了 public static implicit operator DBField<T>(T value) 和 public static implicit operator T(DBField<T> value)，以及覆盖 == 和其他比较运算符，以及实现了 IEquatable<DBField<T>>、IComparable 和 {{1 }}。

现在我们正在尝试将 IComparable<DBField<T>> 通过 NUnit 测试，我们在其中相当新。

值得注意的是，我们正在尝试各种等价物：

DBField<T>

前两个断言通过，后两个断言失败。

每个断言的内部运作似乎有所不同。有人能解释一下吗？
更准确地说，使用断点调试似乎表明 string z_strComment = "Comment"; _objOrder2.OrderComment = z_strComment; //[...] Assert.True("Comment" == _objOrder2.OrderComment); Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment)); Assert.That(_objOrder2.OrderComment, Is.EqualTo("Comment")); Assert.Equals("Comment", _objOrder2.OrderComment); 测试 Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment));我希望它反过来。我错过了什么吗？
我知道 _objOrder2.OrderComment.Equals("Comment") 和 True() 比 Equals() 年长。在哪些情况下哪些更可取？

Answer 1

这里有两件事在起作用：

如果测试失败，来自 NUnit 的错误消息有多大用处
您使用的是什么风格的 NUnit API

Assert.True("Comment" == _objOrder2.OrderComment)

如果此测试失败，您会收到类似“预期为真，为假”的消息。没有帮助，因为它没有告诉您 _objOrder2.OrderComment 的实际值是什么。

Assert.Equals("Comment", _objOrder2.OrderComment);
Assert.That(_objOrder2.OrderComment, Is.EqualTo("Comment"));

这两个是等价的，第一个使用略短的语法，第二个使用更具扩展性的 constraint model（您可以编写自己的断言，例如 Assert.That(x, new MyConstraint(y))）。

如果测试失败，您会得到类似 Expected "Comment", was "Actual Value" 的信息。这样更有帮助。

Assert.That("Comment", Is.EqualTo(_objOrder2.OrderComment));

这个是倒退的。如果失败，您会得到类似 Expected "Actual Value", was "Comment" 的信息，这是错误的。

关于旧式 Assert.Equals 与约束模型 Assert.That，这（令人讨厌）取决于个人喜好。我个人使用 Assert.Equals 是因为我觉得它更容易阅读，但是在对集合进行断言时我会使用 Assert.That 而不是 CollectionAssert，并且我也会在编写自己的断言时使用它.

阅读下面一位 NUnit 开发人员的评论，了解他们如何发现用户更容易理解 Assert.That 样式。

NUnit - Equal(this, that), True(this == that) 还是 That (this, Is.EqualTo(that))？

1 个答案: