设备通信器的 TDD

Question

我一直在阅读有关 TDD 的资料，并想将它用于我的下一个项目，但我不确定如何使用这种新范式构建我的类。我想使用的语言是 Java，尽管问题并不是真正特定于语言的。

项目

我有一些带有 ASCII-over-RS232 接口(interface)的硬件。我可以发出简单的命令，得到简单的响应，并像从它们的前面板一样控制它们。每一个都有略微不同的语法和非常不同的命令集。我的目标是创建一个抽象/接口(interface)，以便我可以通过 GUI 和/或远程过程调用来控制它们。

问题

我相信第一步是创建一个抽象类(我不擅长命名，'Communicator' 怎么样？)来实现串行 I/O 等所有内容，然后为每个设备创建一个子类。我敢肯定它会比这复杂一点，但这是我心目中应用程序的核心。

现在，对于单元测试，我不认为我真的需要实际的硬件或串行连接。我想做的是将一个 InputStream 和 OutputStream(或 Reader 和 Writer)交给我的 Communicators，它们可以来自串行端口、文件、stdin/stdout，从测试函数通过管道传输，等等。那么，我是否可以让 Communicator 构造函数将这些作为输入？如果是这样，很容易将所有设置的责任都放在测试框架上，但对于真实的事物，谁进行实际连接？一个单独的构造函数？再次调用构造函数的函数？一个单独的类(class)，谁负责将 Communicator“连接”到正确的 I/O 流？

编辑

我正要重写问题部分以获得我认为我要问的问题的答案，但我想我想通了。我已经(正确地？)确定了两个不同的功能区域。

1) 串口处理

2) 与设备通信(了解其输出并生成命令)

几个月前，我会把它们合并到一个类中。我摆脱这种做法的第一个想法是仅将 IO 流传递给理解该设备的类，但我无法弄清楚谁将负责创建这些流。

在对控制反转进行了更多研究后，我想我有了一个答案。有一个单独的接口(interface)和类来解决问题 #1，并将其传递给解决问题 #2 的类的构造函数。这样，很容易分别测试两者。 #1 通过连接到实际硬件并允许测试框架做不同的事情。 #2 可以通过模拟 #1 来测试。

这听起来合理吗？我需要分享更多信息吗？

Answer 1

使用 TDD，您应该让您的设计浮现，从小处着手，循序渐进，一点一点地通过测试扩展您的类。

澄清:从一个具体的类开始，发送一个命令，使用模拟或 stub 对其进行单元测试。当它足够工作时(可能不是所有选项)，在你的真实设备上测试一次，以验证你的模拟/ stub /模拟器。

一旦第一个命令的类可以运行，就开始以相同的方式实现第二个命令:首先再次模拟/ stub ，然后一次针对设备进行验证。现在，如果您发现两个类之间有相似之处，您可以重构为基于抽象类的设计——或者不同的东西。