设备通信器的TDD

Question

我一直在阅读关于TDD的内容，并希望将其用于我的下一个项目，但我不确定如何使用这种新范例构建我的类。我想使用的语言是Java，但问题并不是特定于语言的。

项目

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

的问题

我认为第一步是创建一个抽象类（我坏名，怎么样“通讯”？）来实现所有喜欢串行I/O的东西，然后为每个设备创建一个子类。我相信它会比这更复杂一些，但这是我脑海中应用程序的核心。

现在，对于单元测试，我不认为我真的需要实际的硬件或串行连接。我想要做的是将我的Communicators作为一个InputStream和OutputStream（或Reader和Writer），它可以来自串口，文件，stdin/stdout，从测试函数传送，不管。那么，我是否只需将Communicator构造函数作为输入？如果是这样，将责任全部放在测试框架上很容易，但对于真正的人来说，谁来建立真正的连接呢？一个单独的构造函数？函数再次调用构造函数？一个单独的课程是将Communicator“连接”到正确的I/O流的工作？

编辑

我正要改写问题部分为了得到答案，我想我是问这个问题，但我想我想通了。我（正确地？）确定了两个不同的功能区域。

1）与所述设备（理解其输出&生成命令）

几个月前通信的串行端口

2）处理，我会它全部合并成一个类。我第一个想摆脱这种情况的想法是将IO流传递给理解设备的类，我无法弄清楚谁将负责创建流。

已经做了更多的控制反转研究，我想我有和答案。有一个单独的接口和类来解决问题＃1并将其传递给解决问题＃2的类（es？）的构造函数。这样，分开测试都很容易。 ＃1连接到实际的硬件，并允许测试框架做不同的事情。 ＃2可以通过给予＃1的模拟来测试。

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

Answer 1

随着TDD，你应该让你的设计出现，从婴儿的步骤开始小，并通过测试，一点一点地增长你的课堂测试。

CLARIFIED：从一个具体的类开始，发送一个命令，单元测试它与模拟或存根。当它足够工作（可能不是所有选项）时，请对照您的真实设备进行一次测试，以验证您的模拟/存根/模拟器。

一旦第一个命令的类可操作，开始执行第二个命令，同样的方法：首先再次你的模拟/存根，然后一次针对设备进行验证。现在，如果你看到两个类之间有相似之处，你可以重构你的基于抽象类的设计 - 或者不同的东西。

Answer 2

对不起，我是一个小的Linux中心..

我的模拟小玩意喜欢的方式是write character device drivers模仿他们的行为。这也给你提供了很多有趣的功能，比如提供一个ioctl（）接口，使仿真设备的行为异常。

在这一点上......从测试到现实世界，只关心您实际打开，读取和写入的设备。

模仿你的小工具的行为不应该太难......听起来他们会采取非常基本的指令并返回非常基本的回应。再次，一个简单的ioctl（）可以告诉模拟设备它的时间行为不当，所以你可以确保你的代码充分处理这些事件。例如，故意在每个第n条指令上失败，其中n是在调用ioctl（）时随机选择的。

Answer 3

在看到您的编辑后，我认为您正朝着正确的方向前进。 TDD倾向于推动你采用由小班组成的设计，并有明确的责任。我也会回应tinkertim的建议 - 您可以控制和“激发”以不同方式运行的设备模拟器对测试非常有用。