“测试驱动的软件开发”,与测试无关

Test-Driven Development Is Not About Testing

Summary
I am always on the look out for good questions to ask candidates in an interview. Not the "How many oranges can I fit in this room?" kind of nonsense (the stock response to which is apparently "with or without us standing in it?").
By Dan North 
Page 1 of 1

I am always on the look out for good questions to ask candidates in an interview. Not the "How many oranges can I fit in this room?" kind of nonsense (the stock response to which is apparently "with or without us standing in it?"). Nor the picky, encyclopedic type such as "In the javax.obscure.DustyCorner class, which method throws a FullyDocumentedException?" (If you do not respond with "I would check the Javadocs" on the grounds that you actually know, you really ought to get out more.)

Instead, I like the sort of technical question that allows candidates to demonstrate real insight; where they can show not only technical depth and breadth, but also a mature understanding of the software development process. So I was delighted when a colleague offered me a perfect interview question, namely: "What is the point of test-driven development?"

Test-driven development (TDD) has grown out of the Agile software movement (www.agilealliance.org) and Extreme Programming (XP) in particular. Extreme Programming stipulates a set of best practices that collectively encourage core values such as feedback and simplicity. The feedback occurs in the form of tests, by delivering in short iterations, and by the simple expedient of talking to one another. The simplicity comes from the process of refactoring - ruthlessly - and from only delivering exactly what the software has to do right now.

Kent Beck, the original champion of XP, has extracted the essence of its development practices and named it test-driven development. And so to the model interview answer. The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.

We start by writing some client code as though the code we want to develop already existed and had been written purely to make our life as easy as it could possibly be. This is a tremendously liberating thing to do: by writing a model client for our code, in the form of a test, we can define programmatically the most suitable API for our needs. In addition, we assert the behavior we want.

Obviously this won't even compile, and this is the counterintuitive part - the code that will sit on the other side of the API doesn't even exist yet! The next stage is to write the minimum amount of code to get the test compiling. That's all, just a clean compile, so you can run the test (which at this stage will fail). IDEs such as IntelliJ IDEA or the open source Eclipse will generate missing classes and implement missing methods for you. Now, and only now, you write the application code to satisfy the test. The final piece of the puzzle is to refactor the code so it's as simple as it can be. This then becomes your development rhythm: write a test, write some code, refactor.

Writing the test before you write the code focuses the mind - and the development process - on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests.

We keep the tests we wrote and run all of them, often, to make sure the system does everything it is supposed to do (and to alert ourselves immediately if we break any existing functionality). However, the extremely useful test suite we've created is very much a secondary benefit of the TDD process.

So when you're sitting in an interview and someone asks you about testdriven development, remember that it's not about the tests; it's about seeing how little you actually need to do and how cleanly you can do it! If someone asks you to fill a room with oranges? Well, I'll leave that to you.

What do you think? Join the Feedback to this item.

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: libusb是一款跨平台的开源库,它提供了一套独立于硬件的API,用于在USB设备上进行通信和控制。作为一个万能驱动调试工具,它在USB驱动开发和测试中非常有用。 首先,libusb提供了一个简洁而强大的API,使得开发者能够轻松地与USB设备进行通信。开发者可以使用libusb来发送和接收USB数据,控制USB设备的配置和接口,以及管理USB设备的插拔等操作。使用libusb,开发者可以根据自己的需求自定义USB操作,而无需依赖特定的驱动程序或操作系统。 其次,libusb还提供了丰富的调试功能,使得开发者能够更好地调试USB驱动程序。libusb可以帮助开发者打印USB设备的状态信息和错误信息,以便更快地定位和解决问题。此外,libusb还支持在不同操作系统上的调试功能,包括Windows、Linux和Mac OS X等。开发者可以利用这些调试功能来分析USB设备的行为,并对驱动程序进行更加准确和高效的调试。 最后,libusb还具有跨平台的优势,这意味着开发者可以在不同的操作系统上使用相同的API和工具进行USB驱动开发和调试。这样一来,开发者可以更加方便地在不同平台上测试和验证USB驱动的兼容性和稳定性。 总的来说,libusb作为一个万能驱动调试工具,为开发者提供了丰富的API和调试功能,帮助他们更好地开发和调试USB驱动程序。它的跨平台性能和简洁易用的特点,使得开发者能够更加高效和准确地进行USB驱动开发和测试工作。 ### 回答2: libusb是一个开源的跨平台的用户空间USB驱动库。它提供了一组API,可以方便地编写驱动以访问USB设备。 libusb作为万能驱动调试工具的优点有以下几点: 1. 平台无关性:libusb适用于多个操作系统,包括Windows、Linux、Mac等。这意味着开发人员可以使用相同的代码进行跨平台的开发和调试,无需为每个平台单独编写驱动程序。 2. 灵活性:libusb可以与各种类型的USB设备通信,包括存储设备、串口设备、音频设备等。开发人员可以利用libusb提供的API进行USB设备的读写操作,并进行调试和测试。 3. 易用性:libusb提供了简单易用的API接口,开发人员可以轻松地实现对USB设备的读写操作。此外,libusb还提供了丰富的文档和示例代码,方便开发人员学习和使用。 4. 调试能力:libusb提供了调试工具,如libusb_debug和libusbx,在开发和调试过程中可以启用调试输出,以帮助开发人员追踪和解决问题。这些调试工具可以输出详细的USB通信信息,如请求、响应和错误信息,有助于定位和解决驱动问题。 总之,libusb作为万能驱动调试工具具有平台无关性、灵活性、易用性和调试能力。它为开发人员提供了便利和强大的工具,可以加快USB设备驱动程序的开发和调试过程,从而提高开发效率和质量。 ### 回答3: libusb是一个开源的跨平台的USB驱动库,它提供了一套简单易用的API,使得开发人员可以直接与USB设备进行通信。这也意味着我们可以使用libusb作为一个通用的调试工具,来调试USB设备的驱动。 使用libusb作为万能驱动调试工具的原因有以下几点: 1. 跨平台支持:libusb可以在多个操作系统平台上运行,包括Windows、Linux、Mac等。这样,无论开发人员使用的是哪个操作系统,都可以使用libusb进行驱动调试。 2. 强大的功能:libusb提供了许多功能,如枚举USB设备、打开和关闭USB设备、发送和接收数据等。通过这些功能,我们可以方便地检测设备的状态、读取设备的数据、发送指令等。 3. 灵活的调试方式:利用libusb,我们可以以各种方式与USB设备进行通信,这使得驱动调试更加灵活。例如,我们可以通过发送特定的指令来触发设备的某些行为,或者读取设备的内部寄存器状态等。 4. 可视化工具支持:除了使用libusb库进行编程,还有一些可视化工具可以与libusb配合使用。这些工具可以提供更直观的界面,方便开发人员对USB设备进行调试和监控。 总结起来,libusb作为一个跨平台的USB驱动库,可以提供强大的功能和灵活的调试方式,使得开发人员可以方便地进行USB设备的驱动调试工作。无论是在软件开发中还是硬件调试中,libusb都是一个值得推荐的工具。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值