如何在现实世界的项目中选择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那样的婴儿步骤.我可以在客户端嘲笑sosmething然后我必须知道这个事情要提前嘲笑,所以我需要一些前期设计.

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

什么方式是正确的去？我们应该始终从最高层开始(如何处理这个需要的巨大步骤)？我们可以从实现所需特征的微小部分的任何类开始(在本例中为Formatter)吗？

如果我知道在哪里打我的测试,我会更容易继续.

Answer 1

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

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

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