如何用硬件进行TDD

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

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

那时我们还没有使用TDD。我们确实考虑过为硬件编写一个模拟器,这样我们就可以单独测试程序,但由于我们不知道硬件应该如何工作,很难编写一个准确的模拟器,所以最终我们没有这样做。如果我们对硬件有更好的了解,我们本可以为它创建一个模拟器的,这将使开发程序变得更加容易。用真实硬件进行测试是最有价值的,事后看来,我们应该花更多的时间用硬件进行测试。

2. 第二部分与模型进行了对比。此部分自动运行。

在您确保硬件连接正确等之后,将手动运行第1部分。一个好主意是创建一套针对工厂返回的东西运行的测试,并运行这些测试两次:一次针对返回真实“驱动程序”的工厂,一次针对模拟对象的工厂。这样,您可以确保您的模拟与真实的模拟完全一样:

class YourTests extends TestCase {
    public IDriver getDriver() { return new MockDriver (); }
    public boolean shouldRun () { return true; }
    public void testSomeMethod() throws Exception {
        if (!shouldRun()) return; // Allows to disable all tests
        assertEquals ("1", getDriver().someMethod());
    }
}

class HardwareTests extends YourTests {
    public IDriver getDriver() { return new HardwareDriver (); }
    public boolean shouldRun () { return "yes".equals (System.getProperty("manual")); }
}

如果硬件接口很简单,比如串行端口,你可以很容易地使用环回电缆让你的程序与模拟硬件通信。几年前,我在编写软件与信用处理器对话时使用了这种方法。我的测试应用程序被认为我的模拟器是一个调制解调器和后端处理器。

或者,根据设备的不同,您可以使用标准测试设备(信号发生器等)为其提供“已知输入”。

请注意,这会导致您同时测试硬件和设备驱动程序的问题。不幸的是,这真的是现阶段你唯一的好选择——任何模拟硬件都可能与真实设备大不相同,无法进行测试。

在测试套件中包含访问硬件的测试可能不是一个好主意。这种方法的一个问题是,测试只能在连接到这种特殊硬件的机器上运行,这使得很难将测试作为(夜间)自动构建过程的一部分运行。

• 一个可以访问真实硬件的程序,您可以手动运行
• 访问作为自动测试一部分运行的软件模块

当我在机顶盒上工作时,我们有一个工具,可以从任何带有doxygen注释的C API生成mock。

然后,我们用我们希望硬件返回的内容对模拟进行初始化,以便对我们的组件进行单元测试。

我们用来生成模拟的工具在内部,所以我帮不了你。但有一些有希望的谷歌热门:

• http://code.google.com/p/googlemock/
• http://www.opensourcetesting.org/unit_c.php
• http://spin.atomicobject.com/2006/12/29/cmock-ruby-based-mock-tools-for-c

很难用这么少的细节来回答这些问题:-)