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