Osheep

时光不回头,当下最重要。

一切从测试开始--《测试驱动开发》读后感

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

让一切从测试开始,这是一个很好的实践。

点赞