我正在手工制作新代码。我想确保我不遗余力。
除了指定代码合同来指导 Pex 以便它在数字密集型代码中产生良好的覆盖率之外，我还能做些什么具体的事情？
尝试在http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdf中搜索关键字“float”以获取一些背景信息。
浮点数的算术约束通过转换为有理数来近似，启发式搜索技术在 Z3 之外使用以找到浮点约束的近似解。
...并且...
符号推理。Pex 使用自动约束求解器来确定哪些值与测试和被测代码相关。然而，约束求解器的能力是有限的，而且永远是有限的。特别是，Z3 无法精确推理浮点运算。
或者，您是否知道 .NET 下更适合在 .NET 下查找数值异常的工具？我知道http://fscheck.codeplex.com/但它不执行符号推理。
是你想要的良好覆盖吗？仅仅在一段代码中运行每个分支的测试不太可能实际上意味着它是正确的——通常更多的是关于极端情况，作为开发人员的你最有可能知道这些极端情况是什么。听起来它也可以通过说“这是一个有趣的输入组合”来工作，而你想要的很可能是指定你想看到的系统的行为——如果你一开始就写错了代码，那么有趣的输入可能与正确的代码完全无关。
也许这不是您正在寻找的答案，但我会说最好的方法是手动！在开始编码之前写下规范，并在您知道/正在为您的类/子系统编写 API 时将其转化为大量测试用例。
As begin filling out the API/writing the code you're likely to pick up extra bits and pieces that you need to do + find out what the difficult bits are - if you have conditionals etc that are something you feel that someone refactoring your code might get wrong then write a test case that covers them. I sometimes intentionally write code wrong at these points, get a test in that fails and then correct it just to make sure that the test is checking the correct path through the code.
然后试着想想你可能没有涵盖的任何奇怪的值——负输入、空值等。通常这些情况是无效的，你不想迎合/不得不考虑——在这些情况下，我通常会写一些测试说他们应该抛出异常——这基本上可以阻止人们在你没有正确/使用无效数据的情况下滥用代码。
这样做的另一个好处是，如果您意识到算法需要彻底重写才能满足一些新要求，那么您所要做的就是添加新的测试用例，然后重写/重构；如果您的测试只是查看算法的细节并假设对外部世界的影响，那么您将非常头疼，试图弄清楚算法当前如何影响行为，哪些部分是正确的，哪些不是，然后试图将大量单元测试迁移到新的 API/算法上。