|
这是我第二次读《测试驱动开发》这本书，第一次读的时候，我刚刚从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对于一个开发来说它的魅力何在，我也对以通过测试为目的进行开发有了一点新的理解。对于我来说，一个功能有各种场景，一开始就想全想好是一个很烧脑的过程，在写好代码之后回忆代码都实现了哪些场景，然后编写单元测试也很累，而且还可能会漏掉某些场景。但是先写好测试场景，是一个很好的让我梳理应用场景的过程，并且可以很好的引导我的思维。每添加一个测试，我要做的就只是做一点改变，然后让这个测试通过即可，每次我只需要关注很小的一部分就够了。 让一切从测试开始，这是一个很好的实践。 本文转自：简书 微信号：IdeaofSE |
|
|
