python - Python 中的 TDD - 我们应该测试辅助函数吗？

Question

这是一个关于 Python 的理论问题，因为我们几乎可以访问任何我们想要的东西，即使它被下划线标记为“私有(private)”。

def main_function():
    _helper_function_()
    ...
    _other_helper_function()

使用 TDD 进行操作，您遵循Red-Green-Refactor循环。现在的测试如下所示:

def test_main_function_for_something_only_helper_function_does():
    # tedious setup
    ...
    main_function()

    assert something

问题是我的 main_function 有太多设置步骤，因此我决定测试这些特定情况下的辅助函数:

from main_package import _helper_function

def test_helper_function_works_for_this_specific_input():
    # no tedious setup
    ...
    _helper_function_(some_input)

    assert helper function does exactly something I expect

但这似乎是一个不好的做法。我是否应该“了解”任何内部/辅助函数？

我通过将部分内容移至这些辅助函数中，重构了主函数，使其更具可读性。因此，我重写了测试来实际测试这些较小的部分，并创建了主函数确实调用它们的另一个测试。这似乎也适得其反。

另一方面，我不喜欢许多挥之不去的内部/辅助函数的想法，没有专门的单元测试，只有类似快乐路径的主函数。我想如果我在重构之前覆盖了原始函数，我的旧测试就足够好了。

此外，如果主函数中断，这将意味着辅助函数的许多其他测试也会中断。

应该遵循什么更好的做法？

Answer 1

The problem is that my main_function had so much setup steps that I've decided to test the helper functions for those specific cases

太好了，这正是应该发生的事情(测试“驱使”您将整体分解为更容易测试的更小的部分)。

Should I even "know" about any inner/helper functions?

权衡。

是的，模块的部分要点是它们提供 information hiding ，允许您稍后更改代码执行某些操作的方式，而不会影响客户端(包括测试客户端)。

但是直接测试内部模块也有好处；测试设计变得更简单，与不相关细节的耦合更少。每个决策所涉及的测试较少，这意味着当您需要更改其中一个决策时，影响范围会更小。

我通常的想法是这样的:我应该知道有可测试的内部模块，并且我可以知道外部模块的行为它与内部模块耦合，但我不应该必须知道外部模块已耦合到内部模块。

assert X.result(A,B) == Y.sort([C,D,E])

如果你仔细看看这个，你会发现它暗示 X.result 和 Y.sort 今天有一些共同的要求，但这并不一定 promise X.result 调用 Y.sort。

So I've rewritten tests to actually test these smaller parts and created another test that the main function indeed calls them. This also seems counter-productive.

A 有效，B 有效，C 有效，现在您正在为 f(A ，B，C)....是的，事情发生了变化。

TDD 的预期结果是“有效的干净代码”(Jeffries)；事实是，您无需编写世界上的每个测试即可获得可运行的干净代码。

测试在最有可能出现错误的代码中是最重要的 - 我们只是将事物连接在一起的直线代码并没有像具有大量条件和分支的代码那样从红绿重构循环中受益那么多.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies

对于“简单到明显没有缺陷”的代码段，一套自动化程序员测试并不是一项巨大的投资。让两个人进行手动审核，然后签字。