我正在手工制作新代码。我想确保我不遗余力。
除了指定代码合同以指导Pex之外，我还能做些什么吗？所以它在数字密集型代码中产生了良好的覆盖范围？
尝试在http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdf搜索关键字'float'以获取一些背景信息。
浮点数上的算术约束通过对有理数的转换来近似，并且在Z3之外使用启发式搜索技术来找到浮点约束的近似解。
......还有......
符号推理。 Pex使用自动约束求解器来确定哪些值与测试和被测代码相关。但是，约束求解器的能力是，并且总是会受到限制。特别是，Z3不能精确地推理浮点运算。
或者，您是否知道.NET下的工具更适合在.NET下查找数字异常的任务？我知道http://fscheck.codeplex.com/但它没有执行符号推理。
答案 0 :(得分：1)
你想要什么好的报道？只需要在一段代码中运行每个分支的测试实际上不太可能意味着它是正确的 - 通常更多的是关于极端情况，并且您作为开发人员最好知道这些角落案例是什么。它听起来像只是说“这是一个有趣的输入组合”，而你想要的更多可能是指定你想要看到的系统的行为 - 如果你在第一时间编写错误的代码然后有趣的话输入可能与正确的代码完全无关。
也许这不是您正在寻找的答案，但我想说最好的方法就是手工制作！在开始编码之前写下规范，当你知道/当你为你的类/子系统编写API时，将它转换成一堆测试用例。
当开始填写API /编写代码时，你可能会获得额外的点点滴滴，你需要做的事情+找出困难的部分 - 如果你有条件等等你觉得有人重构代码可能会出错，然后编写一个涵盖它们的测试用例。我有时故意在这些点上编写错误的代码，然后进行测试失败，然后纠正它只是为了确保测试正在通过代码检查正确的路径。
然后尝试并考虑你可能没有涵盖的任何奇怪的值 - 负输入，空值等。通常这些都是无效的情况，你不想满足/不得不考虑 - 在这些情况下我会一般写一些测试来说他们应该抛出异常 - 这基本上会阻止人们在没有正确/无效数据的情况下滥用代码。
您在上面提到您正在使用数字密集型代码 - 可能值得测试上面的级别，因此您可以测试您正在寻找的系统中的行为而不仅仅是数字运算 - 假设代码不是纯粹的数值这将帮助您建立一些真实的执行条件，并确保无论数字运算数字实际上正在做什么以您需要的方式与程序的其余部分进行交互 - 如果它是算法，您可能会更好地写作一种验收测试语言，用于帮助表征在不同情况下所需输出的内容 - 这可以清楚地显示您要实现的目标，还允许您通过一个可能比系统更好的（真实）数据计算机生成的输入。这样做的另一个好处是，如果你意识到算法需要大量重写以满足一些新的要求，那么你所要做的就是添加新的测试用例然后重写/重构;如果你的测试只是查看算法的细节并假设对外界的影响，那么你会有一个实质性的头痛试图找出算法当前如何影响行为，哪些部分是正确的，哪些不是然后尝试将大量单元测试迁移到新的API /算法上。