这是我第二次读《测试驱动开发》这本书，第一次读的时候，我刚刚从TWU回来，书里有着太多我刚刚学到的东西，我看完了之后很神奇的，没有对TDD有更深的感悟，反而对JAVA的继承有了一些新的理解。由于十一之前出了一段时间的bug，凯峰老师推荐我再去读一读这本书，读完之后，对TDD有了一些感悟。
首先先简单的介绍一下这本书中主要的概念：测试驱动开发。
测试驱动开发
这里的测试这个概念主要是指自动化测试中的单元测试。单元测试的意义在于，它可以快速的运行，使开发可以快速的获得反馈。而且单元测试越多，覆盖的功能越全，可以极大的增强开发对于代码的信心。测试驱动开发是以测试为优先，先进行测试代码的编写，以通过测试为目的进行开发。
测试驱动开发这件事，在我接触这件事之前，是完全无法想象的。在我学编程的时候，我从来没有想过写测试，编写代码更多的时候是一件一气呵成的事，但是之后手动测试的时候层出不穷的bug、反复的调试是一件极其痛苦的事情。花一晚上写代码，但是花两天的调试简直是常事。
在我接触到测试驱动开发了之后，很多时候也是补测试，就是倒过来的DDT（Development Driven Test）。这是一件很奇怪的事，在TWU的时候，大家学习TDD，将DDT当作一个笑话讲出来，但是回到了工作中，DDT确是常态。有的时候我甚至是恐惧写测试。
《测试驱动开发》这本书里很常见的一句话是，测试可以增强你的信心。在我没接触过自动化测试甚至是接触了一段时间内，我都不知道测试的意义是什么，只是大家说要这样做，我就这样做。但是有一天，我参加一个比赛，碍于时间，我没有写测试，这让我想起了曾经被调试支配的恐惧。那个时候我无比的怀念每天陪伴我的这些测试。
单就测试而不是驱动开发来说，就是让重构变成一件简单的事。每当我做了一点改变的时候，我很恐惧引入bug，所以我跑了一遍测试，测试完好地通过了，我就会稍微安心一些的进行接下来的工作。所以那些没有被测试覆盖的功能让我恐惧，所以每当我不想写测试时，回想一下那些反反复复的调试，我会觉得还是写测试让我更加舒服。
说回测试驱动开发，我有一个很神奇的毛病，当我看一本书的时候，这里边的概念会在一定的时间的深深地影响到我。所以在我看《测试驱动开发》的这段日子，我迎来了一个新功能的代码，新功能不复杂，复杂的是需要与之前的代码进行集成，而且之前的代码还很多，有点乱。我脑子中有一点想法，但是又不知道如何入手。
所以我理所当然的想到了先写一个简单的测试。
我要做的新功能是这样的，我需要调用一个api，这个api会返回给我一系列的response，我根据这些response中的某一个字段来进行状态判断并且存到数据库中。所以对于我来说，最简单的场景就是，我调用api失败了，我没有得到期望的response，我应该存一个有问题的状态进数据库。我只需要添加一小点代码，这个测试就顺利的通过了。这之后我写了一个最常见的happy path的测试场景：我成功的获取了response，并且response的值都是我期待的值，我应该存储一个好的状态进入数据库。根据这个测试，我加入了一定的逻辑进去。这之后我又列举了各种bad path作为测试场景，这些场景驱动我完善了我的代码。代码完成之后的使用真实数据的手动测试也非常的顺利，时间在我看来花费的比想象的要少，而且完成后没有很烧脑很累的感觉。
在我完成这个之后，再回过头来看TDD，才开始明白TDD对于一个开发来说它的魅力何在，我也对以通过测试为目的进行开发有了一点新的理解。对于我来说，一个功能有各种场景，一开始就想全想好是一个很烧脑的过程，在写好代码之后回忆代码都实现了哪些场景，然后编写单元测试也很累，而且还可能会漏掉某些场景。但是先写好测试场景，是一个很好的让我梳理应用场景的过程，并且可以很好的引导我的思维。每添加一个测试，我要做的就只是做一点改变，然后让这个测试通过即可，每次我只需要关注很小的一部分就够了。
让一切从测试开始，这是一个很好的实践。
