文档结构  
可译网翻译有奖活动正在进行中,查看详情 现在前往 注册?
原作者:Itamar Turner-Trauring    来源:codewithoutrules.com [英文]
CY2    计算机    2016-12-15    1评/1648阅
翻译进度:已翻译   参与翻译: vincentsun (7)

如果你遇到过测试驱动的开发(TDD),你可能已经遇到了带有几乎宗教热情的程序员采用这种方法。他们会告诉你在写代码之前必须写单元测试,没有例外。如果你不这么做,你的代码会被永恒的破碎诅咒,永远被邪恶的边界用例折磨。

这是编程中的一个常见的问题:专家的好的建议变成了一个降低生产效率的宗教信仰。基于驱动的开发是很有用的,而且值得采纳... 在有的时候,但不是所有情况下。第一个提出TDD的专家会是第一个告诉你这一点的人。

第 1 段(可获 1.39 积分)

让我们看看专家建议是如何成为宗教的,以及你怎样能避免这件事情发生。

专家建议成为了宗教

专家的问题是,他们有专家盲点。因为专家如此理解一个事情,他们无法将其拆分成概念,并以一种可以理解方式解释给新手。

因此专家可能会说“在写代码前,你一定要写单元测试。”他们实际想说的是:

  1. 在你写代码之前,写单元测试。
  2. 除非这份代码不受单元测试控制,比如由于单元测试对这个特殊种类的代码无法提供丰富的信息。
  3. 或者除非是你打算立刻丢掉的代码。
  4. 从技术上讲你可以在写完代码后写测试,然后再拆分你的代码并逐步测试。但这么做很烦人而且稍微更容易出错,所以作为一个专家我根本不打算提这一点。
第 2 段(可获 2.14 积分)

一个TDD的真实信徒可能会开始反对这些说法。但想想甚至TDD起源的极限编程(Extreme Programming),都讨论了有必要进行单元测试的编程类型。

特别地,极限编程中的一个“spike”是一个体系结构原型,用于找出你打算写的代码的结构。由于它最终会被丢掉,你在写spike的时候不需要写单元测试。你可以在这个极限编程概述中可视化地看到这一点;体系结构的Spike总是在循环之前 发生,而单元测试是作为循环的一部分写成的。

第 3 段(可获 1.26 积分)

如果你认定单元测试适用于所有代码,想想两个例子:单元测试在检测一个密码安全随机数字生成器中没什么用处。而且如果一个电影的导演让你写一段代码来3D渲染一个“看起来非常给力的爆炸”,你同样无法从单元测试中收益太多,除非你写一个单元测试来定义“给力程度”。

所以如果专家知道在写代码前写单元测试不总是对的,他们为什么说“总是 在写代码之前写单元测试”呢?专家盲点:他们无法想象任何人在不该写单元测试的时候写单元测试。

第 4 段(可获 1.36 积分)

对于专家来说,一个原型系统和需要测试的代码,对于不同目标来说,很明显是非常不同的事情。但对于新手听众来说没那么明显。

新手听众会从字面意义上去理解专家的建议,并且相信他们必须在写代码前总是 写单元测试。新手现在变成了一个真正信徒。他们告诉认识的所有人“总是在写代码前写测试”,并且他们试图在所有情况下都这么做。

这样,好的建议转变成了降低生产力的宗教,因为单元测试总在不需要或者不应该出现的时候出现。

第 5 段(可获 1.26 积分)

避免陷阱

你该怎么做来避免这种事情发生在你身上呢?

如果你是个专家,确保解释你的陈述的应用场景。不要说“总是要做X”。而是要说“因为Y,你需要做X,在A的情况下但不是B的情况下。”

如果你不是专家,事情就有点麻烦了。想想要是专家和真正信徒都在做同样的陈述“总是在写代码前写测试”。你怎么能分辨出告诉你这一点的是专家还是真正信徒呢?

你需要听取每一份意见,并弄清楚在什么场景下它不适用。对于一个专家写作的话题,他的假设经常是隐式的,所以这可能给你一些提示。

第 6 段(可获 1.7 积分)

如果你能够与专家双向交流,试图让专家描述他们的陈述的适用范围:让他们提出这个建议不再适用的边界场景。提出你找到的他们的建议似乎无法工作的例子,看看他们说什么。

一个专家如果受到了足够的刺激,能够提出他们的建议不适用的例子,并解释为什么。但一个真正信徒不会退缩,不会接受任何妥协:他们知道真相,而且是绝对的和不可改变的真相。

编程是一个广阔的领域,什么能造就一个好软件取决于你的场景、目标和工具。几乎从没有任何一个答案处处适用。从专家身上学习,但绝不要从真正信徒身上学习。

第 7 段(可获 1.69 积分)

文章评论

vincentsun
推荐一下这篇文章!作者很逗,把一个问题解释得很清楚~