Kevlin Hnney是英国的一位独立参谋和培训师，其关注的规模重要包含软件架构、形式、开发历程温顺序设计言语。在本文中他将谈谈如何通过单元测试进步开发效力。
单元测试只会糟蹋时光吗?某些软件专家们确凿是这么想的。最近在Software Quality Insights上看到一篇文章——《单元测试真的有用吗?》。那些以为单元测试无用的开发人员给出了如下理由：
1。 他们不理解单元测试。
2。 很难写出优良的单元测试。
3。 单元测试只会糟蹋时光、下降效力。
4。 写单元测试须要太多时光(特殊是频繁的迭代开发)。
5。 回归测试更有效力。
本文将重点探讨前面三个问题，即单元测试与开发效力的关系。
效力 vs 人员支配
单元测试会下降效力、形成时光上的糟蹋吗?这取决于所说的效力是什么，以及所说的时光对象是谁。在一个地道编写新代码的周期里，写单元测试的顺序员所写代码能够会比不写单元测试的少。假如所说的效力是指这个，那么单元测试确凿会下降顺序员的效力。
然而，咱们很随意发明这种牵强的效力定义的问题所在。代码行并不是权衡效力的规范，它只是所写代码的行数。从单个类到全部体系，咱们能够发明很多代码行数已经远越过了实践所需。
咱们须要的并不是更多的代码，而是正确的代码。单元测试能够让咱们随时进行代码档次上的实在性检讨，它能够通知咱们能否在开发正确的货色。所以越多的测试就意味着越少的代码。这并不是什么好事。开发速率(development velocity)与开发速度(development speed)的差别就在于方向。向正确的方向行进即便几步也要好于在同伴的方向上飞驰。
另一个同伴的想法是开发人员多数时光都在编写新代码。尽管开发人员也想用心于代码，然而现实却并非如此。会议(与团队、治理人员、客户、投资商等)、邮件、顺序调试、会话、文档制造、装置、钻研评价、赞助处理问题、跟进支撑、兼并版本、处理配置治理体系等都是须要琢磨的。
尽管各部分所占比例依据名目与公司的不同而有所变更，然而这些都是与代码无关的运动，而且所占时光总和要高于编写代码占用的时光。问题在于，假如咱们把一部分编码时光用于单元测试，那么上面这些时光有多少能够转化为编码时光呢?
部分优化 vs 全局优化
看清全局也很重要。上面Alfred Aho说所的对于开发AWK言语的故事颇有一些值得咱们琢磨的中央：
“假如再有这样一次时机，咱们在开发这种言语的时分一定会增添庄重的测试。咱们事先是把AWK当作一种”暂时性(throw-away)“言语进行开发，所以并没有琢磨庄重的质量掌握……曾经有个人用AWK编写了一个CAD体系。他来找我，想通知我AWK编译器的一个Bug。他很生机，说我糟蹋了他三个星期的性命，由于他用了三个星期查找他代码里的同伴，后果却发明是编译器的问题!起初我和Brian Kernighan探讨过这个问题，咱们以为应当做一些质量掌握方面的责任。而后，咱们针对AWK一切功用做了一次庄重的回归测试。从那以后，咱们三人无论谁为这种言语增添新功用的时分，都要先写一份相应的测试。”
这个故事的意义就在于它是对比早的拥戴“测试后行”编程方法的实例——在完成某个功用之前先把测试写进去，而不是只在规划或许行动说说。另外，这个故事也解释了如何把短期、暂时性或针对性代码改变为暂时、稳固的规划。
文章来源于领测软件测试网 https://www.ltesting.net/