Java 单元测试数学代码

我正在编写一个用于计算复杂数学公式的小实用程序（使用commons数学库进行积分和寻根）。我试图以与普通业务应用程序相同的方式编写它，但是我发现我得到的类数量正在迅速增加。为了得到计算的第一步（1行公式和2个积分），我已经为计算的每一个微小部分编写了3个类，这样我就可以使用依赖项注入并正确地模拟对commons math的所有调用。虽然这有点失控，但我最终会用20个类来解决一个问题，这个问题可以在一个类中的两个屏幕上解决（无需单元测试）。你喜欢什么方法？我很想只依靠验收和更高级别的测试来实现这一点。

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

---

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

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

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

一种有时对我有用的技术。。。通常在数学代码中，有“简单但缓慢”的方法和“快速但难以编程”的方法。在编写代码时，您希望使用快速但难以编写的方法（因此您可能会遇到bug）。所以使被测系统（SUT）快速运行。进行单元测试时，创建1000个随机问题，并用“简单但缓慢”的方法解决它们。然后，运行SUT并确保答案是相似的

---

当然假设。。。制造随机问题是一个容易解决的问题。有时是，有时不是。如果你不告诉我们数学代码本身，很难说。现在。。。这是所有的箱子吗？不，但它会得到“普通”案例。如果在实践中出现了一个紧急情况，请在单元测试中对其进行封装，并在下一版本的代码中进行修复。

+1：我同意。但是，无论您做什么，都不要单独忽略此函数的单元测试。如果您这样做了，当您尝试测试包含它的程序集时，您将后悔。我是从痛苦的经历中写出来的。你说的是嘲笑普通数学。我不会那么做的。Commons math是一段可靠的代码。在测试中使用它，而不是模仿它。这是否简化了事情？如果需要模拟20个类，可能是这些类耦合得太紧密了？（高内聚力）。