私有方法的单元测试实践

Question

我目前正在尝试创建一些类来执行傅里叶变换。

我先创建一些单元测试，然后构建基本功能。但问题是，我只能编写一个测试来检查算法是否有效，并知道预期结果。然后开始构建大型算法，如果它有效，则我的单元测试将通过。

我的问题在于，这并不是真正的TDD。因为通常您会创建测试来测试类的基本特征。现在我的类基本上执行一个大算法，而且我无法测试算法的较小部分，因为它们不是公共的（我一直被告知您永远不想测试私有方法）。

你如何处理这个问题？

- Timo Willemsen

Answer 1

我看到有两种可能的方法：

1. 如果可能的话，将算法实现移动到另一个类中，并将其拆分为方法。之后再测试这些方法。
2. 编写一堆测试用例，覆盖可能的正常情况、边缘情况和错误情况。

- zerkms

Answer 2

最近我一直在探讨“什么是单元？”这确实是一个棘手的问题。

如果你有理由相信FFT的子单元特别容易出错，那么就设置边界条件，打破私有方法豁免规则。

另一种说法是，子单元实际上是FFT使用的服务单元，这样你就不会违反任何规则。

- msw

Answer 3

如果你的类只有一个可测试方法（根据你仅测试公共方法的标准），那么你别无选择，只能测试该方法，对吧？然而，这并不意味着它不是 TDD - 你完全可以测试多种输入值。在这里的大部分工作将是找到有趣的值 - 你的转换可能会失败的边缘情况是什么？是否有任何无效的输入数据，以及如何处理？

你是否有办法对许多值进行算法验证，例如调用已知良好的例程，使用一些关键的 Fourier 相关标识，或者使用你的 FFT 进行multiplication？

- BeeOnRope

Answer 4

我认为如果你无法测试算法的各个组件，那么代码要么非常紧密耦合，要么非常过程化。

你可能需要将代码定义为单元，并将这些单元作为受保护的方法。只要该方法受到保护，就会清楚地传达它不是API的一部分。

- uncaught_exceptions

---

无法理解过程式编程风格与测试不可能性之间的联系。过程式代码和面向对象的代码一样可以进行测试。 - zerkms

@zerkms，我同意你的观点，但是我说的是在特定情境下。在过程式编码中，存在着非常紧密耦合的单元（在这种情况下是过程）。我曾经看到过一些代码被写成链式结构，这使得进行单元测试非常困难。 - uncaught_exceptions

你可能已经读过了，但如果没有的话 - 我认为建议阅读一下：Michael Feathers的《与遗留代码有效工作》。 - zerkms

这是关于如何将无法测试的代码改为可测试的内容。我已经阅读了大约50%并变得更加开心;-) - zerkms