学习笔记 Programming TDD
最近在读Kent Beck的《Test-Driven Development By Example》，让我对软件开发有了新的认识。
写test并不为了测试而测试，是为了增强对程序的信心，减少焦虑。那么如何减少焦虑呢，是通过一次只关心一件事情。如何一次只关心一件事情，这就是TDD。
本书分三个部分
- The Money Example
- The xUnit Example
- Patterns for Test-Driven Development
前两个部分讲了两个例子，来阐述如何进行TDD开发，最后一个部分算是总结，全书的精华所在。本文不打算讲这两个例子了，因为例子最好自己手写一遍，才可以加深了解。本文主要摘录一些TDD的模式方法(pattern)。
下面这段话来自第一章，提纲挈领：
My goal is for you to see the rhythm of Test-Driven Development (TDD), which can be summed up as follows.
- Quickly add a test.
- Run all tests and see the new one fail.
- Make a little change.
- Run all tests and see them all succeed.
- Refactor to remove duplication.
The surprises are likely to include.
- How each test can cover a small increment of functionality.
- How small and ugly the changes can be to make the new tests run.
- How often the tests are run.
- How many teensy-weensy steps make up the refactorings.
这就是TDD的精髓。按作者的说法就是Green/Red/Green/Refactor节奏。
这也回答了我一直以来的困扰，到底应该如何设计一段程序，到底要考虑多少种情况。按照TDD的建议就是，首先写测试，然后代码怎么快怎么来，不管有多ugly，然后如果发现重复，及时做重构。不要考虑什么扩展性之类的，这个设计方式本身就能提供。因为它提高了运行测试和重构的频率，既提升了编码者对程序的信心，也降低了不合理设计的可能性。
书中引入了很多影像图(Influence Diagram)，很形象的说明了，引入TDD能给我们日常的开发工作引入什么好处。
This is a positive feedback loop.
- The more stress you feel, the less testing you will do.
- The less testing you do, the more errors you will make.
- The more errors you make, the more stress you feel.
- Rinse and repeat.
能将大块的测试分割成松耦合的小测试不容易，但是好处大大的。作者说：
I never knew exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests.
我们要怎么开始TDD呢？作者给出了很具操作性的建议：
Before you begin, write a list of all the tests you know you will have to write.
这个list上写点什么呢？
- Put on the list examples of every operation that you know you need to implement. 要哪些操作。
- for those operations that don’t already exist, put the null version of that operation on the list.哪些操作没实现，写上存根。
- List all of the refactorings that you think you will have to do in order to have clean code at the end of this session. 完成之后，列出需要重构的地方。而如果有大的重构的需要时，放到later list里面，把手里的事情处理完，再去处理大的重构。
看作者时刻在强调TDD就是tiny steps：
The pure form of TDD, wherein you are never more than one change away from a green bar, is like that three-out-of-four rule.
什么时候写测试？
答：在写code之前，因为一旦你开始写code，你可能就身陷泥潭，无暇顾及test case了。
Each test should represent one step toward your overall goal.
如何开始写测试？不要一开始就想写一个真正的测试，因为这样会一次面对太多的问题。作者建议尝试从一个简单的测试输入输出开始。这样以便于你从Greenxun迅速开始你的Green/Red/Green/Refactor节奏。作者举了一个产生多边形的例子：
1.Reducer r= new Reducer(new Polygon());
2.assertEquals(0, reducer.result().npoints);
不太懂这个问题，不过可以从中看出作者对TDD的解释。问题本身是要解一个降低多边形边数的问题。作者的启动测试就是一个“0”边多边形，那结果一定是”0”边多边形。对实际意义很荒诞，但对测试来说是一个不错的开始。符合我们的预期，简单而且又represent one step toward your overall goal。
这一章是在说如何不用强迫的手段让非TDD的团队成员能转向TDD。当开发者向你解释他的程序时，你都可以将之转化为test case。
本书还有一个很有特色的地方是，贯穿全文，作者总是在经意不经意间流露着各种宝贵的工作经验：如何长期保持更高效的编程？如果你是经理，你如何与你的团队成员一起工作？等等。这一章就有这样一句话：
If you’re a manager or a leader, you can’t force anyone to change the way they work.
What can you do? A simple start is to start asking for explanations in terms of test cases: “Let me see if I understand what you’re saying.
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
—— 百度百科
本书讲的回归测试概念可能略有不同。按照我的理解，作者是想说，在进行完所有的编码以后，你已经对你的要实现的所有东西完成了unknown
known的过程。那么现在，你可以回过头看看，如果这时候重新写一份测试你应该写什么。
回到你针对这个系统的最初的想法来对整个系统做一个测试。以期对整个系统有个整体的评价。
劳逸结合对程序员是非常非常非常重要的！
Shower Methodology:If you know what to type, then type. If you don’t know what to type, then take a shower, and stay in the shower until you know what to type.
TDD Rule: If you don’t know what to type, then Fake It. If the
right design still isn’t clear, then Triangulate.
看看作者提倡的时间管理
- At the scale of hours, keep a water bottle by your keyboard so that biology provides the motivation for regular breaks.
- At the scale of a day, commitments after regular work hours can help you to stop when you need sleep before progress.
- At the scale of a week, weekend commitments help get your conscious, energysucking thoughts off work. (My wife swears I get my best ideas on Friday evening.)
- At the scale of a year, mandatory vacation policies help you refresh yourself completely. The French do this right—two contiguous weeks of vacation aren’t enough. You spend the first week decompressing, and the second week getting ready to go back to work. Therefore, three weeks, or better four, are necessary for you to be your most effective the rest of the year.
What do you do when you are feeling lost? Throw away the code and start over.
作者在这一章告诉你，不要在泥潭越陷越深，不要害怕重新开始。换个伙伴，换个思路，你可能有更好的发现。
这里说的是，如果你觉得这个测试太大，那就要把这个大的测试破成若干个小的测试，然后看看有没有进展。
How do you test an object that relies on an expensive or complicated resource? Create a fake version of the resource that answers constants.
If you want to use Mock Objects, you can’t easily store expensive resources in global variables.要记得清理现场，否则万一其他的代码把他当作真的object在使用，就会出大问题。所以编码最基本的准则是少用全局变量。
Mock Objects encourage you down the path of carefully considering the visibility of every object, reducing the coupling in your designs. 这里说的是，如果你用Mock Object，你就要思考我到底该不该把这个庞然大物暴露给这段代码。这种思考有助于减小耦合性。
How do you test that one object communicates correctly with another? Have the object under test communicate with the test case instead of with the object it expects.
Without Self Shunt
1.# ResultListenerTest
2.def testNotification(self):
3. result= TestResult()
4. listener= ResultListener()
5. result.addListener(listener)
6. WasRun("testMethod").run(result)
7. assert 1 == listener.count
8.
9.# ResultListener
10.class ResultListener:
11. def __init__(self):
12. self.count= 0
13. def startTest(self):
14. self.count= self.count + 1
With Self Shunt
1.# ResultListenerTest
2.def testNotification(self):
3. self.count= 0
4. result= TestResult()
5. result.addListener(self)
6. WasRun("testMethod").run(result)
7. assert 1 == self.count
8.def startTest(self):
9. self.count= self.count + 1
这里举得例子不是很明白。中文译本里，将self shunt翻译成自分流，感觉也是字面翻译。我理解这里想说的是，不一定要定义一个类来做当前被测试类来做的事情，可以在test case里面用该类暴露的接口来做事情。
Self Shunt may require that you use Extract Interface to get an interface to implement. You will have to decide whether extracting the interface is easier, or if testing the existing class as a black box is easier.
这里又看晕了，self shunt跟extract interface有啥关系。
当我们注意到在我们代码结构中超过一个类使用到另一个特殊类中的同一个方法时，此时应该将该类中的方法提取出来放到一个接口（interface）中，并对外提供这个接口以便被用户类访问、使用，这样有利于打破原来多个类与这个特殊类的依赖关系。这个重构手法很容易实现，更重要的是这样做有利于松耦合。 ——网络上的解释
我觉得这里作者提到的extract interface，并不是我们说的重构里的extract interface。这里说要测试A类和B类通信，我们不直接用B类，而用test case与A类通信，以测试通信的A类端接口是否正确。extract interface说的是从B类中extract接口出来到test case中去implement。或者把B类直接当黑盒子在test case中使用。
这个很有用。有些函数或者过程是没有返回值的，我们就可以用Log String的方式来查看该过程或函数有没有被调用。类似我们看trace log一样，通过看trace log能知道机器执行的代码是否正确。
How do you test error code that is unlikely to be invoked? Invoke it anyway with a special object that throws an exception instead of doing real work.
作者经常能给出一些很实用的小经验，这里又来了，看下面。
How do you leave a programming session when you’re programming alone? Leave the last test broken.
当你要转去做另外一件事情，而手头上的事情又没结束时怎么办？让最后一个测试故意的不通过。这样下次就知道从哪儿开始，然后能迅速上手。醍醐灌顶啊！以前都是认为做另外一件事情之前要把手头上的事情弄的尽善尽美，其实不然。怎么做利于后期继续进行，那就应该怎么做。
You will occasionally find a test broken in the integration suite when you try to check in. What to do?
The simplest rule is to just throw away your work and start over. The broken test is pretty strong evidence that you didn’t know enough to program what you just programmed.
什么什么？竟然要我们扔掉我们做的，然后重新开始。就因为我们的测试和integration测试结果不一致。
大师的话总是有道理的，以后要好好考虑这一点。
作者提到的所谓三角法。通俗的说，就是只在必要的时候做抽象或通用化处理。通常是在TDD的重构这一步完成这个抽象的过程。再通俗点说，就是多弄几个case，再总结共同点，之后做抽象
从另一个角度，作者又说了：
I only use Triangulation when I’m really, really unsure about the correct abstraction for the calculation. Otherwise I rely on either Obvious Implementation or Fake It.
How do you implement an operation that works with collections of objects? Implement it without the collections first, then make it work with collections.
中心思想还是一个，从显而易见的地方开始，每次只做一小步，然后一步一步到达最终的目的地。看下面的例子：
1.// 1. fake code
2.public void testSum() {
3. assertEquals(5, sum(5));
4.}
5.private int sum(int value) {
6. return value;
7.}
8.
9.// 2. add arrays
10.public void testSum() {
11. assertEquals(5, sum(5, new int[] {5}));
12.}
13.private int sum(int value, int[] values) {
14. return value;
15.}
16.
17.// 3. add real sum functionality
18.public void testSum() {
19. assertEquals(5, sum(5, new int[] {5}));
20.}
21.private int sum(int value, int[] values) {
22. int sum= 0;
23. for ( int i= 0; i<values.length; i++)
24. sum += values[i];
25. return sum;
26.}
27.
28.// 4. delete unnecessary code
29.public void testSum() {
30. assertEquals(5, sum(new int[] {5}));
31.}
32.private int sum( int[] values) {
33. int sum= 0;
34. for (int i= 0; i<values.length; i++)
35. sum += values[i];
36. return sum; sum;
37.}
细细体会其间的差别吧。
How do you check that tests worked correctly?
Write boolean expressions that automate your judgment about whether the code worked.
作者在这一章又给出了一个很有指导意义的观点。
尽量不要做白盒测试，如果你想做，说明你的设计有问题
这里作者抛出了一个问题，如果有多个测试有类似的代码怎么办？两个选择：
- test case类定义中抽象出类似setUp的函数，来做重复的工作
- 或者用类似代码生成器的东西来为所有需要的测试生成fixture
方法1有时候更符合DRY原则，但它的缺点是，你要记住setUp里面到底做了什么。两种方法都可以，选择更合适的。
所谓的外部fixture，就是要保证测试能恢复环境配置。
在所有测试开始前调setUp，所有测试结束后调tearDown。这就是External Fixture
1./* Adding to tuple spaces. */
2./* Taking from tuple spaces. */
3./** Taking a non-existent tuple. **/
4./** Taking an existing tuple. **/
5./** Taking multiple tuples. **/
6./* Reading from tuple space. */
这一节说的是，如果待测的函数需要抛出异常，用如下的方法：
1.public void testMissingRate() {
2. try {
3. exchange.findRate("USD", "GBP");
4. fail(); // 如果没抛异常就fail
5. } catch (IllegalArgumentException expected) {
6. }
7.}
How do you run all tests together? Make a suite of all the suites—one for each package, and one aggregating the package tests for the whole application.
1.public class AllTests {
2. // 这里有个main，方便直接调用程序开始测试
3. public static void main(String[] args) {
4. junit.swingui.TestRunner.run(AllTests.class);
5. }
6. // 这里有个suite包含了所有test case
7. public static Test suite() {
8. TestSuite result= new TestSuite("TFD tests");
9. result.addTestSuite(MoneyTest.class);
10. result.addTestSuite(ExchangeTest.class);
11. result.addTestSuite(IdentityRateTest.class);
12. return result;
13. }
14.}
作者在这一章引入了一些TDD中会用到的设计模式。有些是写测试时用的，有的是重构时用的，有的两者皆可。下面是本章所有模式的总纲。
What do you do when you need the invocation of a computation to be more complicated than a simple method call?
Make an object for the computation and invoke it.
这里所说的命令是说，把要调用的方法封装成一个object，然后调用那个object
把一些常量参数做成object来传递
When implementing a Value Object, every operation has to return a fresh object,
All Value Objects have to implement equality
1.public boolean setReadOnly() {
2. SecurityManager guard = System.getSecurityManager();
3. if (guard != null) { ) {
4. guard.canWrite(path);
5. }
6. return fileSystem.setReadOnly(this);
7.}
上面这个例子getSecurityManager在不成功时返回Null，然后调用者再判断返回值以决定会不会用空指针来调用成员变量。
这是一个很常见的做法，这样做不好的是，通常这种判断会非常非常多，而且给人一种“会不会有哪里没判断，以后会导致crash？”的担忧。
Null Object设计模式就是让getSecurityManager返回一个特殊的object来取代Null，这样让所有的操作都统一，以减少重复代码。
模板方法。
When you find two variants of a sequence in two subclasses, you need to gradually move them closer together. Once you’ve extracted the parts that are different from other methods, what you are left with is the Template Method.
1.// TestCase
2.public void runBare() throws Throwable {
3. setUp();
4. try {
5. runTest();
6. }
7. finally {
8. tearDown();
9. }
10.}
中文译名为插入式对象。很难理解哪里有这个所谓的“插入”。这个设计模式核心的思想就是消除if...else...的情况。
看作者的例子，解释的很清楚：
1.// Without Pluggable Object
2.Figure selected;
3.public void mouseDown() {
4. selected= findFigure();
5. if (selected != null) // 到处是null判断
6. select(selected);
7.}
8.public void mouseMove() {
9. if (selected != null)
10. move(selected);
11. else
12. moveSelectionRectangle();
13.}
14.public void mouseUp() {
15. if (selected == null)
16. selectAll();
17.}
18.
19.// With Pluggable Object
20.SelectionMode mode;
21.public void mouseDown() {
22. selected= findFigure();
23. // 全部归结到mode子类里面去处理
24. if (selected != null)
25. mode= SingleSelection(selected);
26. else
27. mode= MultipleSelection();
28.}
29.public void mouseMove() {
30. mode.mouseMove();
31.}
32.public void mouseUp() {
33. mode.mouseUp();
34.}
这一节的设计模式和上一节的极为类似。这次要处理掉的是switch...case...而又不用子类继承的方式来动态调用。这里使用的方法叫反射。
反射：通过自身的属性（如类名，方法名）来做相关逻辑
同样看作者的例子
1.void print() {
2. Method runMethod= getClass().getMethod(printMessage, null);
3. runMethod.invoke(this, new Class[0]);
4.}
看到了没getClass，getMethod，这就是反射。有了这个函数既不需要switch来调用不同的printxxx函数(printHtml, printXml…)，也不需要定义子类来调用不同的print函数。
作者在本节最后给出了一段忠告：
Pluggable Selector can definitely be overused. The biggest problem with it is tracing code to see whether a method is invoked. Use Pluggable Selector only when you are cleaning up a fairly straightforward situation in which each of a bunch of subclasses has only one method.
作者说工厂方法提供了灵活性。我是没看出来。对比下面两段代码，这里增加了灵活性？
1.public void testMultiplication() {
2. Dollar five= Dollar five= new Dollar(5);
3. assertEquals(new Dollar(10), five.times(2));
4. assertEquals(new Dollar(15), five.times(3));
5.}
6.
7.public void testMultiplication() {
8. Dollar five = Money.dollar(5); // 工厂方法
9. assertEquals(new Dollar(10), five.times(2));
10. assertEquals(new Dollar(15), five.times(3));
11.}
12.// Money
13.static Dollar dollar( Dollar dollar(int amount) {
14. return new Dollar(amount);
15.}
作者最后给出了一点忠告
You have to remember that the method is really creating an object, even though it doesn’t look like a constructor. Use Factory Method only when you need the flexibility it creates.
中文译名为冒名顶替。根据文中的阐述，我理解这里讲的不是一种设计模式，而只是一种模式，一种特殊情况。指的是如果某一段代码，只将其中的一个名字（类、方法或者变量等等）替换成另外一个名字，就能得到一段新的代码，称为冒名顶替。发现可以Imposter的情况，其实就是发现重复。
1.// 下面这两段代码就只是将RectangleFigure换成OvalFigure，此是为Imposter冒名顶替。
2.testRectangle() {
3. Drawing d= new Drawing();
4. d.addFigure(new RectangleFigure(0, 10, 50, 100)); RectangleFigure(0, 10, 50, 100));
5. RecordingMedium brush= new RecordingMedium();
6. d.display(brush);
7. assertEquals("rectangle 0 10 50 100\n", brush.log());
8.}
9.
10.testOval() {
11. Drawing d= new Drawing();
12. d.addFigure(new OvalFigure(0, 10, 50, 100));
13. RecordingMedium brush= new RecordingMedium();
14. d.display(brush);
15. assertEquals("oval 0 10 50 100\n", brush.log());
16.}
作者还提到另外两个在重构中经常用到的设计模式，本质其实就是Imposter —— Null Object & Composite。
根据上一章作者的观点，组合其实就是一种冒名顶替。作者在本节开头说了：
How do you implement an object whose behavior is the composition of the behavior of a list of other objects? Make it an Imposter for the component objects.
让这个对象称为组成他的对象的冒名顶替者。说起来很拗口。看例子：
1.// Transaction
2.Transaction(Money value) {
3. this.value= value;
4.}
5.// Account
6.Transaction transactions[];
7.Money balance() {
8. Money sum= Money.zero();
9. for (int i= 0; i < transactions.length; i++)
10. sum= sum.plus(transactions[i].value);
11. return sum;
12.}
这个写法的缺点是，当要算OverallAccount时，没辙了，要定义一个新类来处理。一个OverallAccount是一组Account。但OverallAccount其实要做的也是一种累加，和Account做的并没有什么区别。这就是重复。
解决的办法就是所谓的Composite。把要累加的东西抽象出来称为Holdings，Account累加的是Holdings，OverallAccount累加的也是Holdings。
1.Holding holdings[];
2.Money balance() {
3. Money sum= Money.zero();
4. for ( (int i= 0; i < holdings.length; i++)
5. sum= sum.plus(holdings[i].balance());
6. return sum;
7.}
写到这里，我仍然不是特别明白何为Composite（拼合，复合的意思）。但我们是站在巨人的肩膀上，对比阅读了中文译本后有了一点点感觉。这个设计模式的中文译名为-递归组合。所谓递归，应当指的是，通过概念上的抽象，将一个大的混合类写成一些更抽象的概念的组合。例如:
OvreallAccount <- Account <- Transactions
OverallAccount <- Holding & Account <-Holding
通过递归地将OverallAccount冒名顶替成Holding，从而使OverallAccount成为一个Account来达到消除重复。
作者在本节最后给出了何时使用Composite的建议：
As is obvious from this discussion, I’m still not able to articulate how to guess when a collection of objects is just a collection of objects and when you really have a Composite. The good news is, since you’re getting good at refactoring, the moment the duplication appears, you can introduce Composite and watch program complexity disappear.
这个就是很著名的单例模式，经常会用到。作者没有详加阐释，只是告诫读者不要用全局变量(global variable)。我猜作者的意思是，如果要用全局变量，就用单例模式的类对象吧。
在TDD中，重构要做的就是，保证所有测试通过的情况下，降低重复（code之间，code与test之间）。
- How do you unify two similar looking pieces of code? Gradually bring them closer. Unify them only when they are absolutely identical. 不要强制整合，等他们完全相等了再说
- Such a leap-of-faith refactoring is exactly what we’re trying to avoid with our strategy of small steps and concrete feedback. Although you can’t always avoid leapy refactorings, you can reduce their incidence. 不要做跨越式的重构。
- Sometimes you need to approach reconciling differences backward—that is, think about how the last step of the change could be trivial, then work backward. 反向思考，尽量让每一步都非常小(trivial)，这样方便回退。
隔离改动，也就是我们通常做的一些抽象封装。把变化的部分用接口包装起来，这样就达到了隔离的效果。
Some possible ways to isolate change are Extract Method (the most common), Extract Object, and Method Object.
How do you make a long, complicated method easier to read? Turn a small part of it into a separate method and call the new method. 将一个大函数打碎，从中提取一些方法出来。
- Find a region of the method that would make sense as its own method. Bodies of
loop, whole loops, and branches of conditionals are common candidates for extraction. - Make sure that there are no assignments to temporary variables declared outside the
scope of the region to be extracted. - Copy the code from the old method to the new method. Compile it.
- For each temporary variable or parameter of the original method used in the new
method, add a parameter to the new method. - Call the new method from the original method.
- 增强可读性
- 消除重复，当你发现有两个大函数，有一部分是相同的，那就可以提取出来称为新的方法。
- 通过inline把一堆函数放在一起，然后看看哪里可以extract （这一点我感觉应该放在How里面，作者是想承上启下，将inline吧）
inline很玄乎，其实就是把函数的代码复制到调用的地方。好处是什么，作者有话说：
You might like the second version better, or you might not. The point to note here is that you can use Inline Method to play around with the flow of control.
其实就是让你把抽象出来的东西放到一起重新抽象，看看会不会有更好的结果。这也是一种重构的方法。
如何将一个类抽象成一个interface。所谓的interface就是只有纯虚函数的类。
- Declare an interface. Sometimes the name of the existing class should be the name of the interface, in which case you should first rename the class.
- Have the existing class implement the interface.
- Add the necessary methods to the interface, expanding the visibility of the methods in the class if necessary.
- Change type declarations from the class to the interface where possible.
这里提到了两种情况：
- 当你需要抽象出父类时
- 当你用了Mock Object，现在要为这个mock object抽象出一个真正的接口时。作者这里提到了一个小技巧，在这种情况下命名是一个头疼的问题。不妨就把新的interface称为IXXX，例如，原来的叫
File，新的接口就称为IFile
其实就是把一个类的方法移到另外一个类里面。但作者提到了一种情况下，这个方法不适用。就是这个方法修改了原先那个类的数据。
这个话题好像很新鲜，之前看到过很多次，但并没有深究。先看看How：
- Create an object with the same parameters as the method.
- Make the local variables also instance variables of the object.
- Create one method called run(), whose body is the same as the body of the original method.
- In the original method, create a new object and invoke run().
有什么好处？
两个好处
- 在添加复杂逻辑的时候，如果有对一个过程有多种方法，那创建一个方法对象，再扩展起来就很简单
- 在一个复杂函数里extract interface的时候，通常一段code需要5，6个参数，这样的话，虽然函数抽取出来了，但是写法并没有简化多少。这时候如果有方法对象，则在类里面是一个独立的名字空间，会提供额外的便利。
就是把方法调用的参数，变成类成员变量。为什么要这么做？
If you pass the same parameter to several different methods in the same object, then you can simplify the API by passing the parameter once (eliminating duplication). You can run this refactoring in reverse if you find that an instance variable is used in only one method.
这个方法简单实用。
经过31章的学习，作者认为我们已经完完全全有能力成为一个合格的TDD程序员了。在这一章里，作者又总结出很多TDD初学者的问题，给予回答。答案都是一些很实用的忠告，特摘取如下。
作者并没有盲目强调测试重要，也没有说任何地方都要写测试。作者说：
Unless you have reason to distrust it, don’t test code from others.
“Write tests until fear is transformed into boredom.”
只在你不相信你的code时，对他进行测试。测试也不是为了测试而测试，或者为了代码的健壮，测试只是为了减少你的焦虑。让你不要从担心变成烦躁，仅此而已。
哎！真是醍醐灌顶！相见恨晚！
什么样的测试不好？
- Long setup code. 如果为了做一个简单的测试，可能只有几行断言，而为此创建一个巨大的对象，那说明哪里肯定出问题了。
- Setup duplication. 如果你发现有几个测试拥有相同或相似的setup代码，那说明你的测试中有重复的地方。
- Long running tests. TDD tests that run a long time won’t be run often. Suites that take longer than ten minutes
inevitably get trimmed. 一个测试套件不要超过十分钟。否则，反复运行的机会就会急剧降低。 - Fragile tests. Tests that break unexpectedly suggest that one part of the application is surprisingly affecting another part. 如果测试被无情打断，说明你的程序里有耦合。
又被醍醐灌顶了！
TDD appears to stand this advice on its head: “Code for tomorrow, design for today.” Here’s what happens in practice. 不要为未来考虑那么多，简单的让测试通过，然后及时的做重构消除重复，反而能达到更好的设计框架（frameworks）。
这里说的和之前一直强调的思想很一致
If our knowledge of the implementation gives us confidence even without a test, then we will not write that test.
- The first criterion for your tests is confidence. Never delete a test if it reduces your confidence in the behavior of the system.
- The second criterion is communication. If you have two tests that exercise the same path through the code, but they speak to different scenarios for a reader, leave them alone.
这也是我想问的，作者的回答是这本书就是为了这个而写的。
There is a whole book (or books) to be written about switching to TDD when you have lots of code. What follows is necessarily only a teaser.
怎么做？
- So first we have to decide to limit the scope of our changes.
- Second, we have to break the deadlock between tests and refactoring.
- 怎么获得feedback
1) We can get feedback other ways than with tests, like working very carefully and with a partner.
2) We can get feedback at a gross level, like system-level tests that we know aren’t adequate but give us some confidence. With this feedback, we can make the areas we have to change more accepting of change.
名词解释：Extreme Programming - XP极限编程
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
TDD与XP的共通之处：
- Pairing
- Work fresh
- Continuous integration
- Simple design
- Refactoring
- Continuous delivery