单元测试数学代码

不要让测试创建一个完全不可用和不可理解的代码。不要用面向对象的方法过度设计功能性存在。

您正在测试一个函数,即无状态存在,它为相同的参数生成相同的结果。我认为这就是您应该测试它的方法:从所有可能的等价类中为它提供参数,并对结果进行断言。

根据我的经验,您应该使用单元测试作为健全性检查和可能的回归检查。当然,单元测试应该尽可能彻底,但有时让它完全测试代码的全部功能是非常繁琐的。

单元测试不是正式的证明。它们不能也不会解决将来的错误和代码问题。测试代码的常见用例。如果您需要大量的可靠性,那么您需要创建一个大型的回归测试库。幸运的是,对于常见的问题,有一些在线数据库可以处理这类问题。 TPLP 例如,是定理证明者的问题(和解决方案)数据库。

一种有时对我有用的技巧…通常在数学代码中,有“简单但缓慢”的方法,以及“快速但难以编程”的方法。在编写代码时,您希望使用快速但难以编写的代码(因此您希望出现错误)。所以…快速测试系统(SUT)。当你做一个单元测试时,创建1000个随机问题,并用“简单但缓慢”的方法解决它们。然后,运行SUT并确保答案类似。

当然假设…创造随机问题是一个很容易解决的问题。有时是,有时不是。如果你不告诉我们数学代码本身,就很难说。现在。。。所有的案子都是这样的吗?不,但是会有“普通”的病例。如果在实践中出现了一个角落案例,请将其包装在一个单元测试中,并在下一个版本的代码中修复它。