放弃测试优先式开发(TDD)

测试优先或测试驱动开发(TDD)是你在编写程序前先编写测试的软件开发方法。你编写程序来通过测试,扩展测试或增加测试然后再扩展程序功能来通过这些测试。你先花费时间建立一系列的测试,然后你可以在每次程序修改时自动运行测试。这是为了确保每时每刻程序都能够运行并通过测试。你周期性地重构你的程序来提高它的结构并让它易读易改。

外界宣称测试优先式开发提高了测试覆盖率,并且在不改变现有功能基础上,能够更简单的改变程序。测试的作用就像文档一样,你有了一个关于程序应该做什么的详细又抽象的描述。

几个月前,我谨慎的决定体验测试优先式开发。作为一个退休的程序员,我编写的是我私人的项目,而不是一个有文档说明的客户端。所以我在此所说的话或许仅仅适用于没有严格程序文档的情况。

起初,我发现这个方法(测试驱动开发)很有用。但我开始实现一个 GUI 时,编写测试很困难,而且我认为编写测试所花费的时间并不值得。然后,我并没有完全(或许是不纯粹地)按照TDD的要求去实现,所以我没有对所有东西做自动化测试,有时在编写测试前就实现了一些东西。

但是,我并不是因为编写 GUI 自动化测试的(众所周知的)困难而放弃 TDD 。我放弃是因为我认为它在编程中鼓励保守主义,它鼓励你设计能通过测试的决策,而不是符合用户的正确决策,它使你专注于细节而不是架构,并且它并不能适用于主要的一类程序问题——那些由意外的数据引起的问题。

  • 因为你想确保你总是可以通过大多数的测试,当你改变并扩展程序时你倾向于思考这一点。你因此不情愿做出会导致大量测试失败的大范围的变更。从心理上讲,你变得保守并避免破坏大量测试。
  • 往往对程序设计做测试比其他更容易。有时,最棒的设计是很难测试的,所以你不情愿采取这种方法,因为你知道你将花费大量时间设计并编写测试(对于我来说真的是一件无聊的事)。
  • 对于我来说最严重的问题是 TDD 鼓励专注于整理细节来通过测试,而不是把程序看做一个整体。我每次开始编程时只有有限的上机时间,并且需要花费时间审视并思考程序整体。我认为这带来优雅又优秀的结构化程序。但是 TDD 让你深入程序不同部分的细节,很少能够退后一步审视大局。
  • 根据我的经验,很多程序出现失败是因为处理的数据并不是程序所期待的。编写能够精确反映出你将要处理的坏数据的「坏数据」测试很困难,因为你需要成为一个领域专家并理解数据。「纯粹主义者」解决这点,当然,那就是你设计了数据校验检查,所以你不需要处理坏数据。但是现实中通常很难定义什么是「正确的数据」,并且有时你不得不处理你得到的数据而不是你预期的数据。

所以,我回到原点开始先写代码,然后写测试。我继续在有意义的地方做自动化测试,但在我能清楚读懂代码并理解它做什么的时候,我不会花费大量荒谬的时间编写测试。思考优先比测试优先是一条更好的路。

附言。我很确定 TDD 纯粹主义者会说我做的不正确,所以没有真正从 TDD 受益。或许他们是对的。但是我还没有找到狂热者能够说服我。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

2 2 收藏 1 评论

关于作者:孙腾浩

毕业于郑州大学软件工程专业,身为 Java 程序猿却同样热爱着 JavaScript 。为了兴趣而写代码,做自己喜欢做的事。Keep coding ... Stay Cool ... 个人主页 · 我的文章 · 18 ·   

相关文章

可能感兴趣的话题



直接登录
最新评论
  • PunCha 程序员 01/16

    我放弃是因为我认为它在编程中鼓励保守主义,它鼓励你设计能通过测试的决策,而不是符合用户的正确决策,它使你专注于细节而不是架构,并且它并不能适用于主要的一类程序问题——那些由意外的数据引起的问题。

    很同意作者的观点!TDD只适用于项目整体框架搭出来了,类啊函数的骨架都有了,再用TDD的方式实现函数。

跳到底部
返回顶部