原创 2003年11月07日 01:03:00

Test-Driven Development Is Not About Testing

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.


我接触软件测试这个概念已经很久了,但还是首次这么近距离系统地学习它。 在刚开始学习本专业的时候,我还意识不到测试的重要性,总是在程序基本完成的时候才发现漏洞百出。有时会出现很多bug,debug的时...
  • hengbao4
  • hengbao4
  • 2016年05月03日 21:59
  • 1830


测试是开发中必不可少的工作   首先,一个软件产品或系统的开发成功,不仅仅是编写完为使用者提供服务功能的程序而已。软件程序编写的完成,其实只是完成了开发任务中的一半。与程序的开发相配合的、具有同...
  • CNHK1225
  • CNHK1225
  • 2015年06月25日 15:27
  • 3660


  • KerryZhu
  • KerryZhu
  • 2010年03月22日 21:13
  • 15190


  • hedaogelaoshu
  • hedaogelaoshu
  • 2015年03月05日 16:34
  • 463


所谓的测试桩,就是你负责测试的模块/方法所调用的,所以你需要模仿他们做一个返回值(假的,但符合设计)。 桩的英文是stub;是指一个软件模块的框架或特殊目标实现,主要用于开发和测试一个组件,该组件调...
  • pfm685757
  • pfm685757
  • 2017年02月08日 19:24
  • 2024


测试驱动开发 测试驱动开发基本思想是,开发人员先编写测试用例,再编写能通过用例的代码。就像砌砖师傅先用桩子拉上线再砌墙一样。 思想: •       Test Driven Developme...
  • huver2007
  • huver2007
  • 2017年04月21日 08:53
  • 223


  • imgsq
  • imgsq
  • 2016年05月19日 11:28
  • 893


本文采用nfs挂载网络文件系统的方式,手动创建设备节点, 动态加载驱动模块,对理解驱动编写流程有很大好处! 一、初级驱动执行流程: 1、写好Makefile文件,里面包含将应用程序编译成ap...
  • dcx1205
  • dcx1205
  • 2015年05月21日 00:20
  • 1992


  • justfly
  • justfly
  • 2010年10月24日 05:28
  • 1238


  • foruok
  • foruok
  • 2016年04月11日 07:22
  • 11932