.net - Pex(测试生成)真的有用吗？

Question

是的，可以对“总和”或“除法”等函数的边界值进行测试。 Pex 是一个很好的工具。

但更多的时候，我们会创建对商业行为的测试。让我们考虑经典贝克的 tdd 书中的例子:

[Test]
public void ShouldRoundOnCreation()
{
  Money money = new Money(20.678);
  Assert.AreEqual(20.68,money.Amount);
  Assert.AreEqual(2068,money.Cents);
}

这个测试可以生成吗？否 :) 我的项目中 95% 的测试检查业务逻辑，并且无法生成。

Pex(尤其是与 Moles 配对)可以提供 100% 的代码覆盖率，但是测试套件的高代码覆盖率并不表示代码经过了良好的测试 - 它只会提供对所有内容都经过测试的错误信心。这是非常危险的。

所以，问题是 - Pex 真的有用吗？

Answer 1

我认为您在使用 Pex 的方式上有误:我们强烈建议用户在参数化单元测试中编写断言。

如果您编写断言，Pex 将系统地尝试使它们无效 - 这就是 Pex 的强大之处:您编写的断言越多，它就越会尝试为您查找错误。

如果您在不编写断言的情况下使用 Pex 获得高代码覆盖率测试套件，您只会得到您所要求的:代码覆盖率和有保证的运行时异常。 Pex 'only' 尝试覆盖分支(1 个断言 = 1 个分支)，如果没有要覆盖的分支(无断言)，它将不会生成有趣的测试用例。

一般来说，在参数化单元测试中编写断言更难编写，因为......它们更通用。让我们从舍入行为开始:肯定存在允许舍入发生的界限，这应该自然地转化为参数化单元测试:

[PexMethod]
public void RoundInBounds(double value) 
{
    var money = new Money(value);
    // distance between value and amount should be at most 0.01/2
    Assert.AreEqual(value, money.Amount, 0.005);
}

还有许多模式可用于编写这些模式。例如，您的 'Money' 类可能是幂等的:如果您将 'Amount' 的值反馈到 Money 实例中，您将返回 Amount。这优雅地转换为参数化的单元测试:

[PexMethod]
public void RoundIsIdempotent(double value) 
{
     var first = new Money(value).Amount;
     var second = new Money(first).Amount;
     Assert.AreEqual(first, second, 0.0001);
}

另请注意，参数化单元测试绝对属于 TDD 世界。只需先编写参数化单元测试，Pex 将找到失败的错误，修复错误，Pex 找到下一个失败的错误，等等......

这是否使 Pex 成为一个有用的工具？你是法官。