技术文章 专栏收录该内容
34 篇文章 0 订阅

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.

  • 0
  • 0
  • 0
  • 一键三连
  • 扫一扫,分享海报

测试驱动编程是 XP 困扰程序员一个方面。对于测试驱动编程意味着什么以及如何去做大多数人都做出了不正确假设。这个月XP 方面讲师兼 Java 开发人员 Roy Miller 谈论了测试驱动编程是什么它为什么可以使程序员生产力和质量发生巨大变化以及编写测试原理。请在本文相随 论坛中提出您就本文想法以飨笔者和其他读者。(您也可以单击本文顶部或底部“讨论”来访问该论坛。) 最近 50 年来测试一直被视为项目结束时要做事。当然可以在项目进行之中结合测试测试通常并不是在 所有编码工作结束后才开始而是一般在稍后阶段进行测试。然而XP 提倡者建议完全逆转这个模型。作为一名程序员应该在编写代码 之前编写测试然后只编写足以让测试通过代码即可。这样做将有助于使您系统尽可能简单。 先编写测试 XP 涉及两种测试: 程序员测试和 客户测试测试驱动编程(也称为 测试为先编程)最常指第一种测试至少我使用这个术语时是这样。测试驱动编程是让 程序员测试(即单元测试 ― 重申一下只是换用一个术语)决定您所编写代码。这意味着您必须在编写代码之前进行测试测试指出您 需要编写代码从而也 决定了您要编写代码。您只需编写足够通过测试代码即可 ― 不用多也不用少。XP 规则很简单:如果不进行程序员测试则您不知道要编写什么代码所以您不会去编写任何代码。 测试驱动开发(TDD)是极限编程重要特点它以不断测试推动代码开发既简化了代码又保证了软件质量。本文从开发人员使用角度介绍了 TDD 优势、原理、过程、原则、测试技术、Tips 等方面。 背景 一个高效软件开发过程对软件开发人员来说是至关重要决定着开发是痛苦挣扎还是不断进步喜悦。国人对软件蓝领不屑对繁琐冗长传统开发过程不耐使大多数开发人员无所适从。最近兴起一些软件开发过程相关技术提供一些比较高效、实用软件过程开发方法。其中比较基础、关键一个技术就是测试驱动开发(Test-Driven Development)。虽然TDD光大于极限编程测试驱动开发完全可以单独应用。下面就从开发人员使用角度进行介绍使开发人员用最少代价尽快理解、掌握、应用这种技术。下面分优势原理过程原则测试技术Tips等方面进行讨论。 1. 优势 TDD基本思路就是通过测试来推动整个开发进行。而测试驱动开发技术并不只是单纯测试工作。
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
钱包余额 0