[译] 单元测试之迷思 (摘要)

[gemfeeling]

此文为 "Unit Test Fetish" 一文的摘要。因为读到此文之前，俺只是在实践中模糊地发觉和秉承此观念，只是隐隐觉得单元测试并非改善工程质量之良方，也曾用邮件与异地的同事激辩过单元测试之实质作用，但并未找到会心一击直接KO对方，这其实也说明俺还没点到问题的实质。直到读到此文俺才强烈共鸣，作者把俺没有想通想透的东西，用浅显的话解释得非常清楚，俺是边读边与自己的想法一一印证，阅读带来的愉悦感无逾于此。择要编译于此，这样更多的同学也可从中受益。

http://gulu-dev.com/post/2014-07-19-unit-test-fetish-excerpt

[SoloCompany]

A 的观点：单元测试是负累，重构一下代码，就都废了

B 的观点：今天需要重构代码，居然没有单元测试，于是需要多花两天时间补充测试代码然后才能开始着手重构代码

你更同意哪个观点？

[est]

国内这种PM连需求都分析不清楚，就不要瞎搞单元测试了。怎么快出活怎么不被客户发现破绽才是王道。

[yxz00]

互联网应用单元测试还是很容易的。关键像游戏这种，跟体验相关，跟时间相关的，真是没办法写用列。

[takato]

感谢分享～
我觉得方法都是理念的工具，想要提高质量还是得需要一个良好的理念才行。
单元测试与代码覆盖率只是一个辅助衡量的工具。

[akfish]

有一种人就是喜欢这样，明知道xxx不能/不适合用来做某件事，他就非要去做，然后写篇文章说：看吧，xxx毛用都没，别用了，谁用谁sb。
这是行为艺术么。

[gemfeeling]

@akfish 有一种人就是喜欢这样，明知道xxx意在揭示某事物的不足，以便读者能对照印证，用其所长而避其所短，在实践中能灵活地取舍而不是拘泥于教条。他就非要高冷傲娇地板起面孔，从情绪上一通批判，于事于理本身却只字不提，言之无物。
这是在秀智商么。

[gemfeeling]

@akfish 借用您的口吻，开个玩笑，别见怪。

[gemfeeling]

@yxz00 是的，游戏的话个人经验是完整的交互测试更有用，比如一个命令循环加载所有地图，一个命令加载所有人物的所有动作，一个命令模拟玩家一局游戏，等等。

[gemfeeling]

@est 一次性的怎么来都行，需要维护的下点功夫还是值得的。

[gemfeeling]

@SoloCompany 目前来看，在进度的重重压力下，B通常都很难成为选项。

另，单元测试写多了就知道，这可不仅仅是 “多花两天时间” ，呵呵。