tdd - 如何使用硬件进行 TDD

Question

我工作的所有项目都与一个硬件接口(interface)，这通常是软件的主要目的。有什么有效的方法可以将 TDD 应用于与硬件一起工作的代码？

更新:对不起，我的问题没有更清楚。

我使用的硬件是从相机捕获图像的图像采集卡。然后我处理这些图像，显示它们并将它们保存到磁盘。我可以使用存储在磁盘上的先前捕获的图像来模拟捕获图像后发生的所有处理。

但这是我要测试的与硬件的实际交互。例如，当没有连接相机时，我的软件是否正确处理，是否正确启动和停止抓取等。但这与硬件紧密相关，我不知道当硬件不存在时如何测试它或如果我什至应该尝试这样做？

第二次更新:我也在寻找一些具体的例子来说明人们是如何处理这种情况的。

Answer 1

创建一个薄层来控制硬件，并使用完整硬件的系统测试(手动或自动)以确保控制层按预期工作。然后创建控制层的假/模拟实现，它的外部行为类似于真实硬件的接口(interface)，并在为程序的其余部分执行 TDD 时使用它。

几年前，我正在编写使用 SQUID 磁力计进行测量的软件。硬件很大，不可移动且昂贵(video)，因此不可能始终访问硬件。我们有关于设备通信协议(protocol)的文档(通过串行端口)，但文档不是 100% 准确的。

对我们帮助很大的是创建一个软件，它可以监听来自一个串行端口的数据，记录它并将其重定向到另一个串行端口。然后我们能够找出旧程序(我们正在替换)如何与硬件通信，并对协议(protocol)进行逆向工程。它们是这样链接的:旧程序 <-> 虚拟环回串行端口 <-> 我们的数据记录器 <-> 真实串行端口 <-> 硬件。

那时我们没有使用 TDD。我们确实考虑过为硬件编写一个模拟器，以便我们可以单独测试程序，但是由于我们不知道硬件应该如何工作，所以很难编写一个准确的模拟器，所以最后我们没有做。如果我们更了解硬件，我们可以为它创建一个仿真器，它会使程序的开发变得更加容易。用真正的硬件进行测试是最有值(value)的，事后看来，我们应该花更多的时间在硬件上进行测试。