《测试驱动开发》读书笔记

kent back写的书一向很薄, 薄但是都是干货, 在这个资讯爆炸的年代, 的确节省了大家无数的时间, 测试驱动开发是一本非常厉害的书, 作为测试驱动开发这一开发模式几乎颠覆了我们已有的开发模式, 而要掌握或者领悟这项开发技术却需要经过严格的实战, 非简单的看看书就行的. 虽然我依旧采用传统的开发模式: 先实现, 在写测试. 但是依然朝着TDD的方向继续前进. 希望有一天能完全理解TDD的精髓.

这本书包含三部分:第一部分是用一个资金实例来讲解如何实施TDD, 据说这个例子back在做TDD咨询培训的时候已经用了几十次遍了, 屡试不爽. 通过这个例子, 你会神奇的发现TDD切切实实是一种非常cool的开发方式. 第二部分是xUnit实例, 要有python基础才能看得懂, 如果你跟我一样, 可以略过了, 第三部分是测试驱动开发的模式, 老实说, 我也没有怎么看懂.难道是因为还没有找到TDD的门?算了, 以后回头再来看好了, 说不定那天开了窍, 就能豁然开朗了^_^

测试驱动开发是任何软件工程师都可以学习的一个技术的集合, 它鼓励采用简单的测试和增强自信的测试套件. 如果你是个天才, 你根本不需要学习这些浅显的规则, 如果你是个傻子, 学了也没用, 对于像我们这样介于两者之间的大多数人来说, 遵从着两条简单的规则可以使我们更加接近我们全部潜能的效率去工作.
在你写任何代码之前, 先写一个会失败的自动测试程序.
消除重复设计, 优化设计结构

有关测试驱动开发最难讲清楚的一种东西就是它把你所带到的那种思维状态.

实战
我们将建立一个计划清单, 以提醒我们需要做哪些事情, 它使我们始终保持注意力集中.

我们不是从建立对象开始, 而是从测试开始.

在编写测试的时候, 我们总是为我们的操作设想最完美的接口, 在TDD看来这个颠倒的.

我们要解决的编程问题, 已经由原来的"实现多种币种"转化为"让这个测试程序能够工作, 然后让剩下的测试也能够工作".

你也许不喜欢这个解决方案, 但是现在的目的不是活的最完美的解决方案, 而是让这个测试程序可以运行. 我们将在做出理想的产品之前做出点牺牲.

每一次的工作由以下环节组成:

• 新增一个测试
• 运行所有的测试程序并失败
• 做一些小小的改动.
• 运行所有的测试程序, 并且全部通过.
• 重构代码以消除重复设计, 优化设计结构.

测试驱动开发并非一定要采取这样一小步一小步的开发过程, 而是要培养你将软件开发化为这样一小步一小步的开发任务的能力. 我日复一日都以这样笑的步伐进行开发吗?当然不是. 但是当情况变得有些棘手时, 我很高兴我有这样的能力. 选择一个简单的例子一步一步来尝试, 来学习. 如果你可以将软件开发分成一个个粒度比较小的开发任务, 那么你自然可以将它分的大小合适.

尽快地让测试程序可以运行是压倒一切的中心任务.

尽快使测试可运行的两条策略:
伪实现:返回一个常量并逐渐用变量代替常量, 直到伪实现代码成为真实实现的代码.
显明实现:将真实的实现代码键入.
在实际开发中, 我们可以交替使用这两种方式.

在任何设计不够明了的地方, 我将用伪实现和重构, 我希望通过这些让你看到测试驱动开发是怎样帮你控制开发步伐的大小的.

如果我是在同某个不十分清楚我编写这段代码的意图的人一起编程, 或者是代码逻辑略显一丝复杂的话, 我就会为其编写单独的测试程序.

如果你手头有一个大型系统, 那么你经常改动的部分应该是绝对坚实的, 因此你才能执行的进行每日的修改.

掌握TDD
你应该测试:

• 条件部分
• 循环部分
• 操作部分
• 多态性

但只测试你编写的代码, 除非有理由不信任, 否则就不要测试其他来源的代码.

为明天编码, 为今天设计

测试驱动开发对测试的观点就是注重实效, 在测试驱动开发中, 测试从某种意义上说是一种达到目的的手段:达到充满自信地编码的目的, 如果我们队实现有充分的了解, 不用测试就拥有自信的话, 那么就没有必要编写测试了.

测试越多越好, 但是如果两个测试互为冗余, 你应该保留他们两个吗?这酒取决于下面两个标准:
第一个标准就是自信, 如果删除一个测试降低了你对整个系统功能的信心, 那么就不要删除.
第二个标准就是沟通.如果你有两个测试, 走的是同一条路, 但对读者来说讲述的是不同的情形的话, 那么就应该原封不动的保留.
也就是说, 如果你有两个 , 他们就自信和沟通而言都是冗余的, 那就删除掉其中用处最少的那个.

评论

1 楼 scorris 2009-08-27  

[size=xx-small][/size]