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

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

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.

为什么要学习软件质量保证与测试这门课?

我接触软件测试这个概念已经很久了,但还是首次这么近距离系统地学习它。 在刚开始学习本专业的时候,我还意识不到测试的重要性,总是在程序基本完成的时候才发现漏洞百出。有时会出现很多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

Android实现简单字符驱动程序及测试

这看来老罗的Androidzhilv
  • 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

开发和测试之间的关系

简单来说。开发人员既生产代码,也生产Bug。因为开发人员不可避免地会生产Bug,所以测试人员必须存在,以便在软件交付之前尽可能多地检出Bug,保证交付给客户的软件质量更好一些。一个产Bug,一个挑Bu...
  • imgsq
  • imgsq
  • 2016年05月19日 11:28
  • 893

linux最简单的驱动编写及测试流程

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

软件项目开发团队与测试团队的合作并共赢

软件开发团队和测试团队之间的关系是复杂而有趣的,双方有共同目标,又互相竞争。双方的共同目标在于减少软件交付之后缺陷的严重程度和数量。双方的利益竞争在于测试人员尽可能的发现软件开发团队交付的软件产品的缺...
  • justfly
  • justfly
  • 2010年10月24日 05:28
  • 1238

为什么开发与测试老掐架呢

让我们思考几个常见的问题:软件测试的目的是什么?开发人员能否构建出没有Bug的完美软件?测人人员和开发人员:……...
  • foruok
  • foruok
  • 2016年04月11日 07:22
  • 11932
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:“测试驱动的软件开发”,与测试无关
举报原因:
原因补充:

(最多只允许输入30个字)