单元测试中的不确定性

Question

似乎在许多单元测试中,参数化测试的值要么自己烘焙到测试中,要么以预定的方式声明.

例如,这是从nUnit的单元测试(EqualsFixture.cs)中获取的测试:

[Test]
public void Int() 
{
    int val = 1;
    int expected = val;
    int actual = val;

    Assert.IsTrue(expected == actual);
    Assert.AreEqual(expected, actual);
}

这具有确定性的优点; 如果您运行一次测试,并且它失败,它将继续失败,直到代码被修复.但是,您最终只会测试一组有限的值.

不过我不禁觉得这是浪费; 完全相同的测试可能在项目的整个生命周期中使用完全相同的参数运行数百次甚至数千次.

如何尽可能多地随机输入所有单元测试,以便每次运行都有一些新的东西？

在前面的例子中,也许:

[Test]
public void Int() 
{
    Random rnd = new Random();
    int val = rnd.Next();
    int expected = val;
    int actual = val;
    Console.WriteLine("val is {0}", val);
    Assert.IsTrue(expected == actual);
    Assert.AreEqual(expected, actual);
}

(如果代码需要一个字符串,那么每次都可以使用已知对特定函数有效的随机字符串)

好处是你运行测试的次数越多,你知道它可以正确处理的更大的可能值集.

这有用吗？邪恶？这有缺点吗？我是否完全忽略了单元测试的重点？

谢谢你的想法.

Answer 1

您希望您的单元测试是可重复的,这样除非代码更改,否则它们将始终以相同的方式运行.然后,如果代码更改并导致单元测试失败,则可以修复代码并且单元测试已达到其目的.此外,您知道在单元测试再次通过时代码[可能]已修复.

进行随机单元测试可能会发现异常错误,但这不是必需的.如果您知道代码是如何工作的(比较白盒和黑盒方法来测试),使用随机值不应该显示任何非常随机的单元测试.而且我不愿意被告知"运行几次测试,这个错误应该出现".

Answer 2

你的提议很有意义，前提是你做得正确。您不必总是只听传统观点，即在测试中决不能有不确定性。

真正重要的是每个测试必须始终使用相同的代码路径。那不是完全一样的事情。

您可以在单元测试中采用我所说的受约束的非确定性。这可以驱使您采用更加面向规范的方式来编写测试。