language-agnostic - TDD - 重构为黑盒？

Question

我有一个使用 TDD 开发的重要服务对象。它从一个简单的任务开始:对于队列中的对象，构建异步处理的尝试。所以我围绕我的 constructAttempt() 方法编写了一个测试:

void constructAttempt() {...}

有很多可能的场景需要考虑，所以我对这个方法进行了十几个测试。

---

然后我实现了我真正需要它做的事情:扫描整个队列并构建一批尝试。所以代码看起来更像:

public void go() {
    for (QueuedItem item : getQueuedItems()) {
        constructAttempt(item);
    }
}

所以我为这个 go() 方法添加了一两个新的测试。

---

最后我发现我需要一些预处理，这有时可能会影响 constructAttempt()。现在代码看起来更像是:

public void go() {
    preprocess();
    for (QueuedItem item : getQueuedItems()) {
        constructAttempt(item);
    }
}

---

我对现在应该做什么有一些疑问。

我应该保持代码原样，单独测试 constructAttempt()、preprocess() 和 go() 吗？为什么是/为什么不？我冒着不涵盖预处理和破坏封装的副作用的风险。

或者我是否应该重构我的整个测试套件以仅调用 go()(这是唯一的公共(public)方法)？为什么是/为什么不？这会使测试更加模糊，但另一方面它会考虑所有可能的交互。实际上，它会成为仅使用公共(public) API 的黑盒测试，这可能不符合 TDD。

Answer 1

go 方法实际上只是编排几个交互，其本身并不是很有趣。如果您针对 go 而不是您的从属方法编写测试，则测试可能会非常复杂，因为您必须考虑 preprocess 和constructAttempt(甚至可能是 getQueuedItems，尽管这听起来相对简单)。

相反，您应该为从属方法编写测试 - constructAttempt 的测试需要考虑所有预处理的潜在影响。如果您不能模拟那些副作用(通过操纵底层队列或测试替身)重构您的类，直到您可以。