使用Assert.That（而不是假设）与[Theory]是否是错误的？

Question

interface IPoint 
{ 
    int X { get; } 
    int Y { get; } 
} 

static bool CoincidesWith(this IPoint self, IPoint other); // implementation unknown 

我想写一个NUnit的测试验证有关的CoincidesWith意思我的假设：

self.CoincidesWith(other)⇔（self.X = other.X）∧（self.Y = other.Y）

以下是迄今为止我能够想出的最简洁的测试：

[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); 
} 

个

我的问题，在重要性依次递减，分别是：

1. 随着[Theory]，是不是算错了，还是坏的风格，使用Assert.That，而不是Assume.That？ （The documentation seems to suggest that the latter should be used in conjunction with [Theory].）
2. 这种情况确实更适合[Theory]而不是[Test]？

Answer 1

经过一番思考后，我得出结论：我的上述解决方案没有任何问题。

是这种情况下的确更适合[Theory]而不是[Test]？

如果用于CoincidesWith方法的实现是可用的检查（如源代码），或者至少充分证明，那么就没有必要做假设—我可以简单地查找我需要什么知道。在这种情况下，[Test] —或xUnit.net称为测试，[Fact] —似乎更合适。

但是由于我无法访问CoincidesWith的实现，并且文档不足，所以我需要对该方法的一般工作做一些假设或[Theory]。

随着[Theory]，是不是算错了，还是坏的风格，使用Assert.That，而不是Assume.That？

不是，它只是另一个使用的工具，并不比Assert.That更合适。

在[Theory]的背景下，Assume.That似乎是把额外的限制所提供的[Datapoints]权手段，同时检验实际的假设（使用这些数据点，使得它过去Assume.That）留给Assert.That。

一个例子可以说明这一点。让我们试着写一个测试这种假设：

鉴于偶数a和奇数b，他们的产品a * b是偶数。

测试如果a * b甚至只有满足前提条件才有意义。如果a不是一个偶数，或者b不是一个奇数，测试既不会成功也不会失败;它应该是不确定的。这正是Assume.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) { … }