[英]Is it wrong to use Assert.That (rather than Assume.That) with a [Theory]?
interface IPoint
{
int X { get; }
int Y { get; }
}
static bool CoincidesWith(this IPoint self, IPoint other); // implementation unknown
I want to write a NUnit test that verifies my assumption about the meaning of CoincidesWith
: 我想编写一个NUnit测试,以验证我对
CoincidesWith
含义的假设:
self.CoincidesWith(other)
⇔ (self.X
=other.X
) ∧ (self.Y
=other.Y
)self.CoincidesWith(other)
⇔(self.X
=other.X
)∧(self.Y
=other.Y
)
The following is the most succinct test I've been able to come up with so far: 以下是到目前为止我能提出的最简洁的测试:
[Theory]
void CoincidesWith_Iff_CoordinatesAreEqual(IPoint self, IPoint other)
{
bool coordinatesAreEqual = (self.X == other.X && self.Y == other.Y);
Assert.That(self.CoincidesWith(other) == coordinatesAreEqual);
}
My questions, in descending order of importance, are: 我的问题按重要性从高到低依次为:
[Theory]
, is it considered wrong, or bad style, to use Assert.That
instead of Assume.That
? [Theory]
,使用Assert.That
代替Assume.That
是否被认为是错误的或不良的风格? ( The documentation seems to suggest that the latter should be used in conjunction with [Theory]
. ) [Theory]
结合使用。 ) [Theory]
rather than a [Test]
? [Test]
更适合[Theory]
[Test]
吗? After some more thought, I've come to the conclusion that there is nothing wrong with my above solution. 经过一番思考后,我得出的结论是我的上述解决方案没有任何问题。
Is this case indeed more suitable for a
[Theory]
rather than a[Test]
?这种情况确实比
[Test]
更适合[Theory]
[Test]
吗?
If the implementation for the CoincidesWith
method were available for inspection (eg as source code), or at least well-documented, then there would be no need to make assumptions — I could simply look up what I need to know. 如果
CoincidesWith
方法的实现可用于检查(例如,作为源代码),或者至少有充分的文献证明,则无需进行假设-我可以简单地查找我需要知道的内容。 In that case, a [Test]
— or, as xUnit.net calls tests, a [Fact]
— would seem more appropriate. 在这种情况下,
[Test]
(或xUnit.net称测试为[Fact]
)似乎更合适。
But since I have no access to the implementation for CoincidesWith
, and the documentation is insufficient, I do need to make some assumption, or [Theory]
, about the general working of the method. 但是,由于我无法访问
CoincidesWith
的实现,并且文档不足,因此,我确实需要对该方法的一般工作作一些假设或[Theory]
。
With
[Theory]
, is it considered wrong, or bad style, to useAssert.That
instead ofAssume.That
?使用
[Theory]
,使用Assert.That
代替Assume.That
是否被认为是错误的或不良的风格?
No. It's just another tool to be used, and neither less nor more appropriate than Assert.That
. 否。它只是要使用的另一种工具,而且比
Assert.That
少Assert.That
。
In the context of a [Theory]
, Assume.That
would seem to be the right means of putting additional constraints on the supplied [Datapoints]
, while verifying the actual assumption (using those datapoints that make it past Assume.That
) is left to Assert.That
. 在
[Theory]
的上下文中, Assume.That
这似乎是对所提供的[Datapoints]
施加附加约束的正确方法,同时验证了实际假设(使用使它们超出Assume.That
那些数据点)。 Assert.That
。
An example can illustrate this. 一个例子可以说明这一点。 Let's try to write a test for this assumption:
让我们尝试为此假设编写一个测试:
Given an even integer
a
and an odd integerb
, their producta * b
is even.给定一个偶数整数
a
和一个奇数整数b
,它们的乘积a * b
是偶数。
Testing if a * b
is even only makes sense once the preconditions are met. 仅当满足前提条件时,才测试
a * b
是否有意义。 If a
is not an even integer, or b
is not an odd integer, the test should neither succeed nor fail; 如果
a
不是一个偶数整数,或者b
不是一个奇数整数,则测试既不应成功也不应该失败; it should be inconclusive. 应该没有定论。 And that's exactly what
Assume.That
helps achieve. 而这正是
Assume.That
。这有助于实现。 The actual test, however, is left to Assert.That
: 但是,实际测试留给
Assert.That
:
[Theory]
void GivenAnEvenIntegerAndAnOddInteger_ProductIsAnEvenInteger(int a, int b)
{
Assume.That(a.IsEven());
Assume.That(b.IsOdd());
// note: the type system already ensures that `a` and `b` are integers.
int product = a * b;
Assert.That(product.IsEven());
// note: the theory doesn't require `product` to be an integer, so even
// if the type system didn't already assert this, we would not test for it.
}
[Datapoints]
int[] integers = { 1, 2, 3, 4, 5, 6, 7 };
static bool IsEven(this int integer) { … }
static bool IsOdd(this int integer) { … }
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.