TDD的三条规则(中英对照)

 

The Three Rules of TDD.

TDD的三条规则

邓辉 译

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:

这些年来， 我喜欢用下面三条简单的规则来描述测试驱动开发：

1. You are not allowed to write any production code unless it is to make a failing unit test pass.

1 、除非为了使一个失败的unit test通过，否则不允许编写任何产品代码

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

2 ．在一个单元测试中只允许编写刚好能够导致失败的内容（编译错误也算失败）

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

3 、只允许编写刚好能够使一个失败的unit test通过的产品代码

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can't write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

 

对于任何功能，都必须以编写针对该项功能的unit test开始。根据规则2，在unit test中，你不能编写太多的内容。只要一出现该unit test代码不能编译通过，或者断言失败，就必须停下来开始编写产品代码。根据规则3，你所编写的产品代码应该以刚好能够使得unit test编译或者测试通过为准。

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

仔细想想，就会发现如果不是为了编译或者执行某些东西，你根本不能编写任何代码。事实上，这正是关键所在。我们在做任何事情时（无论是写测试、写产品代码还是重构），都要保证系统能够一直运行。运行测试的间隔时间是秒或者分钟级的。即使是10分钟都太长了。

Too see this in operation, take a look at The Bowling Game Kata.

如果想了解实际的操作过程，可以看看“The Bowling Game Kata”

（译者注： Kata 是目前北美和欧洲一些领先的软件咨询公司开创的一种用于 掌握 软件开发技能的手段，类似于武术中的 招式。目的就是试图寻找出软件开发中的一些 招式，让学习者可以不断演练，从而打下一个良好的基础。 ）

Now most programmers, when they first hear about this technique, think: "This is stupid!" "It's going to slow me down, it's a waste of time and effort, It will keep me from thinking, it will keep me from designing, it will just break my flow." However, think about what would happen if you walked in a room full of people working this way. Pick any random person at any random time. A minute ago, all their code worked.

目前有很多程序员，当他们第一次听到这种技术时都会认为：“这种做法太愚蠢了！”。“这种方法会降低我的开发速度，这样做就是时间和精力的浪费，它会让我无法思考，无法设计，它会打断我的思路。”不过，请试着想一想，当你走进一个坐满了以这种方式工作的人的房间时，会发生怎样的情况。随时、随意选一个人，在一分钟前，他们的代码都是可以工作的。

Let me repeat that: A minute ago all their code worked! And it doesn't matter who you pick, and it doesn't matter when you pick. A minute ago all their code worked!

请让我再重复一遍：一分钟前，每个人的代码都能够工作！不管你选哪个人，不过你在何时去选。一分钟前，每个人的代码都能够工作!

If all your code works every minute, how often will you use a debugger? Answer, not very often. It's easier to simply hit ^Z a bunch of times to get the code back to a working state, and then try to write the last minutes worth again. And if you aren't debugging very much, how much time will you be saving? How much time do you spend debugging now? How much time do you spend fixing bugs once you've debugged them? What if you could decrease that time by a significant fraction?

如果你的所有代码自始至终都可以工作，那么你会频繁使用调试器呢？答案显然是：不频繁。轻松地按几下^Z就可以容易地使代码返回到一个正常工作的状态，接下来把几分钟前的工作重新做一遍即可。如果你不常进行调试，会节省多少时间呢？而现在你花在调试上的时间又有多少呢？在调试完后，你又花了多少时间来修正bug呢？如果你能够大大减少这些时间会怎么样呢？

But the benefit goes far beyond that. If you work this way, then every hour you are producing several tests. Every day dozens of tests. Every month hundreds of tests. Over the course of a year you will write thousands of tests. You can keep all these tests and run them any time you like! When would you run them? All the time! Any time you made any kind of change at all!

好处还不只如此。如果你采用这种方法，那么你每小时都会编写几个测试。一天就是数十个。一个月就是数百个。一年下来，你所编写的测试就会有数千个。你可以保持这些测试并且随时都可以运行它们。什么时候运行它们呢？始终运行！只要你进行了更改，就去运行它们。

Why don't we clean up code that we know is messy? We're afraid we'll break it. But if we have the tests, we can be reasonably sure that the code is not broken, or that we'll detect the breakage immediately. If we have the tests we become fearless about making changes. If we see messy code, or an unclean structure, we can clean it without fear. Because of the tests, the code becomes malleable again. Because of the tests, software becomes soft again.

有些代码我们知道已经混乱不堪了，可是为何不去清理它们呢？因为我们害怕这样做会造成破坏。但是如果我们拥有测试，我们就可以合理的肯定代码没有被破坏，因为测试可以即时地把破坏的地方检测出来。我们看到混乱的代码或者含糊的结构时，我们就可以毫无担心地清理它。因为有了测试，代码重新变得可塑。因为有了测试，软件重新变软了。

But the benefits go beyond that. If you want to know how to call a certain API, there is a test that does it. If you want to know how to create a certain object, there is a test that does it. Anything you want to know about the existing system, there is a test that demonstrates it. The tests are like little design documents, little coding examples, that describe how the system works and how to use it.

好处还不只如此。如果你想知道如何去调用一个特定API，会有一个测试告诉你如何做。如果你想知道如何去创建一个特定对象，会有一个测试告诉你如何去做。关于现有系统你想知道的任何事，都会有一个测试演示给你看。测试就像是小型的设计文档，小型的代码样例，描述了系统的工作和使用方式。

Have you ever integrated a third party library into your project? You got a big manual full of nice documentation. At the end there was a thin appendix of examples. Which of the two did you read? The examples of course! That's what the unit tests are! They are the most useful part of the documentation. They are the living examples of how to use the code. They are design documents that are hideously detailed, utterly unambiguous, so formal that they execute, and they cannot get out of sync with the production code.

你曾经在项目中集成过第三方库吗？你拿到一本相关的厚厚的精致的文档手册，在手册末尾是一沓薄薄的样例附录。你会先看手册的哪一部分呢？当然是样例部分！那些就是unit tests。它们是文档中最为有用的内容。它们是使用代码的真实例子。它们是极其详细、完全没有歧义的设计文档，它们是如此的正规以至于可以运行。它们根本不会和产品代码失去同步。

。
But the benefits go beyond that. If you have ever tried to add unit tests to a system that was already working, you probably found that it wasn't much fun. You likely found that you either had to change portions of the design of the system, or cheat on the tests; because the system you were trying to write tests for was not designed to be testable. For example, you'd like to test some function 'f'. However, 'f' calls another function that deletes a record from the database. In your test, you don't want the record deleted, but you don't have any way to stop it. The system wasn't designed to be tested.

好处还不只如此。如果你曾经为一个已经工作着的系统增加unit tests，你会发现那一点都不好玩。其中，很可能会碰到这样的情形：要么就必须更改系统某个部分的设计，要么就得采用一些欺骗的手段让测试通过，这是因为这个系统本身没有被设计成可测试的。例如：你想测试某个函数f。但是f又调用了另外一个会从数据库中删除一条记录的函数。在测试时，你不希望记录被删除掉，但是你却没有任何阻止的方法。因为系统没有被设计成可测试的。

When you follow the three rules of TDD, all your code will be testable by definition! And another word for "testable" is "decoupled". In order to test a module in isolation, you must decouple it. So TDD forces you to decouple modules. Indeed, if you follow the three rules, you will find yourself doing much more decoupling than you may be used to. This forces you to create better, less coupled, designs.

当你遵循TDD的3条规则时，你的所有代码天生就是可测试的。而“可测试”又意味着“解耦”。为了隔离地测试一个模块，必须要对它进行解耦合。因此，TDD迫使你对模块进行解耦。事实上，如果遵循了这3条规则，就会发现你所做的解耦工作要比以前多得多。而这又推动你创建出更好，耦合更小的设计。

Given all these benfits, these stupid little rules of TDD might not actually be so stupid. They might actually be something fundemental, something profound. Indeed, I had been a programmer for nearly thirty years before I was introduced to TDD. I did not think anyone could teach me a low level programming practice that would make a difference. Thirty years is a lot of experience after all. But when I started to use TDD, I was dumbfounded at the effectiveness of the technique. I was also hooked. I can no longer concieve of typing in a big long batch of code hoping it works. I can no longer tolerate ripping a set of modules apart, hoping to reassemble them and get them all working by next Friday. Every decision I make while programming is driven by the basic need to be executing again a minute from now.

具有这么多好处，这些愚蠢的TDD小规则实际上也许并不愚蠢。它们应该是一些基础性的、意义深远的东西。事实上，在接触TDD前，我已经有近30年的编程经验。我不认为有谁会教我一个低层次的、有实质性不同的编程实践。毕竟30年意味着很多的经验。但是当我开始使用TDD时，这种技术的有效性使我惊呆并使我沉迷其中。我再也无法想象键入一长串代码并期望它能够工作这样的事情了。同时，我再也无法容忍把一系列模块打散，期望到下周5前把它们重新组装起来并使它们正常工作这样的做法了。我在编程时所做的每一个决策都由一分钟后能够再次执行这样的基本需要所驱动。