在现实项目中如何选择TDD起点？

Question

我读过大量文章，看过大量关于 TDD 的截屏视频，但我仍然在实际项目中使用它时遇到困难。我的主要问题是我不知道从哪里开始，第一个测试应该是什么。 假设我必须编写调用外部系统方法（例如通知）的客户端库。 我希望这个客户端按如下方式工作

NotificationClient client = new NotificationClient("abcd1234"); // client ID
Response code = client.notifyOnEvent(Event.LIMIT_REACHED, 100); // some params of call

幕后有一些翻译和消息格式准备工作，因此我想对我的客户端应用程序隐藏它。

我不知道从哪里开始以及如何开始。 我应该为这个库设置一些粗略的类吗？ 我应该像下面这样开始测试NotificationClient吗？

public void testClientSendInvalidEventCommand() {
    NotificationClient client = new NotificationClient(...);
    Response code = client.notifyOnEvent(Event.WRONG_EVENT);
    assertEquals(1223, code.codeValue());
}

如果是这样，通过这样的测试，我被迫立即编写完整的工作实现，而不需要像TDD所述那样采取婴儿步骤。我可以在客户端中模拟一些东西，但是我必须知道要预先模拟这个东西，所以我需要进行一些预先设计。

也许我应该从底部开始，先测试这个消息格式化组件，然后在正确的客户端测试中使用它？

走哪条路才是正确的呢？ 我们是否应该始终从顶部开始（如何处理所需的这一巨大步骤）？ 我们可以从任何实现所需功能的一小部分的类开始（如本例中的 Formatter）吗？

如果我知道在哪里进行测试，那么我会更容易继续进行。

Answer 1

我将从这一行开始：

NotificationClient client = new NotificationClient("abcd1234"); // client ID

听起来我们需要一个NotificationClient，它需要一个客户端ID。这是一件很容易测试的事情。我的第一个测试可能看起来像这样：

public void testNewClientAbcd1234HasClientId() {
    NotificationClient client = new NotificationClient("abcd1234");
    assertEquals("abcd1234", client.clientId());
}

当然，它一开始不会编译 - 直到我编写了一个带有采用字符串参数的构造函数和返回字符串的 clientId() 方法的 NotificationClient 类 - 但这是一部分TDD 周期。

public class NotificationClient {
    public NotificationClient(string clientId) {
    }
    public string clientId() {
        return "";
    }
}

此时，我可以运行测试并观察它失败（因为我已将 clientId() 的返回值硬编码为空字符串）。一旦我的单元测试失败，我就编写足够的生产代码（在 NotificationClient 中）以使测试通过：

    public string clientId() {
        return "abcd1234";
    }

现在我所有的测试都通过了，所以我可以考虑下一步该做什么。显而易见的（嗯，对我来说显而易见的）下一步是确保我可以创建 ID 不是“abcd1234”的客户端：

public void testNewClientBcde2345HasClientId() {
    NotificationClient client = new NotificationClient("bcde2345");
    assertEquals("bcde2345", client.clientId());
}

我运行我的测试套件并观察到 ​​testNewClientBcde2345HasClientId() 失败，而 testNewClientAbcd1234HasClientId () 通过，现在我有一个充分的理由将成员变量添加到NotificationClient：

public class NotificationClient {
    private string _clientId;
    public NotificationClient(string clientId) {
        _clientId = clientId;
    }
    public string clientId() {
        return _clientId;
    }
}

假设没有出现印刷错误，这将使我的所有测试都通过，然后我就可以继续下一步。 （在您的示例中，可能会测试 notifyOnEvent(Event.WRONG_EVENT) 返回一个 Response，其 codeValue() 等于 1223。

）有什么帮助吗？

Answer 2

不要混淆连接到应用程序两端的验收测试，并形成可执行规范，其中 单元测试。

如果您正在进行“纯”TDD，您将编写一个验收测试来驱动单元测试，从而驱动实现。 testClientSendInvalidEventCommand 是您的验收测试，但根据事情的复杂程度，您将把实现委托给多个可以单独进行单元测试的类。

在您必须将它们分开以测试并正确理解它们之前，事情会变得多么复杂，这就是为什么它被称为测试驱动设计。

Answer 3

您可以选择让测试自下而上或自上而下驱动您的设计。两者对于不同情况下的不同开发人员都适用。任何一种方法都将迫使做出一些“预先”设计决策，但这是一件好事。为了编写测试而做出这些决定就是测试驱动设计！

在您的情况下，您知道您正在开发的系统的高级外部接口应该是什么，所以让我们从那里开始。编写一个测试，看看您认为通知客户端的用户应该如何与其交互，并让它失败。该测试是验收或集成测试的基础，它们将继续失败，直到它们描述的功能完成为止。没关系。
现在降一级。提供该高级接口需要执行哪些步骤？我们可以为这些步骤编写集成或单元测试吗？它们是否具有您未考虑到的依赖关系，这可能会导致您更改已开始定义的通知中心界面？继续深入挖掘失败测试的深度优先定义行为，直到您发现实际上已经达到了单元测试。现在实施足够的内容以通过单元测试并继续。让单元测试通过，直到您构建了足够的内容来通过集成测试等等。您最终将完成测试树的深度优先构建，并且应该具有经过良好测试的功能，其设计是由您的测试驱动的。

Answer 4

TDD 的目标之一是通过测试为设计提供信息。因此，您需要考虑如何实现 NotificationClient ，这是一件好事；它迫使你（希望如此）预先考虑简单的抽象。

此外，TDD 有点假设不断重构。您的第一个解决方案可能不会是最后一个；因此，当您改进代码时，测试会告诉您哪些问题，从编译错误到实际运行时问题。

所以我会直接跳进去并开始你建议的测试。当您创建模拟时，您将需要为您所模拟的内容的实际实现创建测试。您会发现事情有意义并且需要重构，因此您需要随时修改测试。这就是它应该工作的方式......