是的，这是可能产生的边界值测试，如心，分化的功能。 PEX是一个很好的工具在这里。

Yes, it is possible to generate tests on boundary values for functions like "Sum" or "Divide". Pex is a good tool here.

但更多的时候，我们创建的商业行为测试。让我们看看例如，从经典的Beck的TDD书：

But more often we create tests on business behaviour. Let's consider example from classic Beck's tdd book:

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

可在测试中产生？没有:)的95％的测试在我的项目检查的业务逻辑，并不能生成。

Can this test be generated? No :) 95 % of tests in my projects check business logic, and can not be generated.

Pex公司（尤其是对与摩尔）可以给100％code覆盖，但一个测试套件的高code覆盖率也从来没有表示，这code是很好的测试 - 它只是给虚假的信心，一切都进行测试。这是很危险的。

Pex (Especially in pair with Moles) can give 100% code coverage, but a high code coverage rate of a test suite does never indicate, that code is well tested - It only gives false confidence that everything is tested. And this is very dangerous.

所以，问题是 - ？是Pex公司非常有用的工具。

So, the question is - Is Pex really useful tool?

推荐答案

我想你是误会Pex的中应该使用的方式。我们强烈建议用户在它们的参数化单元测试写断言

I think you are mistaken in the way Pex should be used: we highly recommend users to write assertions in their parameterized unit tests.

如果你写断言，PEX将尝试系统性地使它们无效 - 这就是Pex公司的力量来自于：你写断言越多，它试图发现漏洞为你

If you write assertions, Pex will try systematically to invalidate them - that's where the power of Pex comes in: the more you write assertions, the more it tries to find bugs for you.

如果您使用的Pex获得高code覆盖测试套件，而无需编写断言，你只能得到你的要求为：code的覆盖范围和保障的运行时异常。 PEX'只有'试图覆盖分支（1断言= 1支），如果没有分支覆盖（不论断），也不会产生interresting测试用例。

If you use Pex to get a high code coverage test suite without writing assertions, you only get what you asked for: code coverage and guaranteed runtime exceptions. Pex 'only' tries to cover branches (1 assertion = 1 branch), if there are no branches to cover (no assertion), it won't generate interresting test cases.

在一般情况下，在参数化单元测试编写的断言更难，因为写的......嗯，他们都比较一般。让我们先从四舍五入行为：必然有一个绑定在其上允许四舍五入的发生，这应该自然地转化为一个参数化单元测试：

In general, writing assertions in parameterized unit tests are harder to write because... well they are more general. Let's start with the rounding behavior: there is certainly a bound on which you allow rounding to occur, this should translate naturally into a parameterized unit test:

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

有也有一些可用于写这些模式。例如，你的钱类可能幂：如果你给'量'回来的钱实例的值，你背量。这优雅转化为一个参数化单元测试：

There are also a number of patterns that can be used to write those. For example, your 'Money' class is probably idempotent: if you feed the value of 'Amount' back in a Money instance, you get Amount back. This translate elegantly into a parameterized unit test:

[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寻找下一个失败的bug，等...

Note also, that parameterized unit tests definitely belong in the TDD world. Just write the parameterized unit test first, Pex will find the failing bug, fix the bug, Pex finds the next failing bug, etc...

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

Does this make Pex a useful tool? You be the judge.