设备通信器的TDD

Question

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

项目

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

问题

我认为第一步是创建一个抽象类（我不擅长名称，'Communicator'怎么样？）来实现Serial I / O之类的所有东西，然后为每个设备创建一个子类。我相信它会比这复杂一点，但这是我脑海中应用程序的核心。

现在，对于单元测试，我认为我不需要实际的硬件或串行连接。我想做的是给我的Communicators一个InputStream和OutputStream（或Reader和Writer），它可以来自串口，文件，stdin / stdout，来自测试函数，无论如何。那么，我是否只需要将Communicator构造函数作为输入？如果是这样的话，将测试框架全部设置在测试框架上是很容易的，但对于真实的事情，谁建立了实际的连接？一个单独的构造函数？再次调用构造函数的函数？一个单独的类是谁将Communicator“连接”到正确的I / O流？

修改

我正要重写问题部分，以便得到我认为我问的问题的答案，但我想我想出来了。我（正确地）确定了两个不同的功能区域。

1）处理串口

2）与设备通信（了解其输出和生成命令）

几个月前，我会将它们全部合并为一个班级。我打破这一点的第一个想法是将IO流传递给理解设备的类，我无法弄清楚谁将负责创建流。

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

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

Answer 1

使用TDD，你应该让你的设计出现，从小做起，按照小步骤，通过测试逐渐增加你的课程测试。

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

第一个命令的类运行后，开始执行第二个命令，方法相同：首先再次使用mock / stub，然后再对设备进行验证。现在，如果你看到两个类之间的相似之处，你可以重构你的抽象类设计 - 或者不同的东西。

Answer 2

抱歉以Linux为中心......

我最喜欢的模拟小工具的方法是编写角色设备驱动程序模拟他们的行为。这也为您提供了有趣的能力，比如提供一个ioctl（）接口，使得模拟设备的行为异常。

此时......从测试到现实世界，只关键实际打开，读取和写入哪些设备。

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

Answer 3

看到你的编辑后，我认为你正朝着正确的方向前进。 TDD倾向于引导您走向由具有明确责任的小班组成的设计。我也会回应tinkertim的建议 - 你可以控制和“挑衅”的设备模拟器。以不同方式行事对于测试是非常宝贵的。