微博热报：单元测试覆盖率

h`;P[ r}:lP'@,G0　　大家针对这个问题给出了各自的意见：

　　吴穹adam：不一定所有行为都必须在单测覆盖的 这个要看分层测试的规划是什么。51Testing软件测试网1?,z0HR@3G$F

6|7uH9D!Ki2U0　　Robin圈：1. 首先，要清楚，在该极端情况下，应不应该出异常。有时候出异常才是期望结果。之后，我们才能决定评审的标准。2. 是否测试是根据价值来分割的，而非事件发生的频率。比如站点初始化，极少发生，却很有测试必要。极端情况，类比分析。51Testing软件测试网N-rs9A_J J(w

　　Ethan苏于登：想问下总体关键，价值在哪里？如果那段代码无价值，就跟若舟想法一样，或许可以删掉。如果代码审核流程不能合适体现价值，应该考虑修改？如果那段代码确实有价值，因为边缘状况确实有可能出现，那加单元测试覆盖其实是很有价值的。

F+EP6t,W uj0　　林曙湧：黑盒测试有一种技术基于风险的测试（RBT），其思想也许可以借用到白盒测试。其基本思想是测试不可能控制全部风险，所以必须面对风险作出抉择，合理安排你的测试投入。其基本公式是 风险=问题发生时的破坏性×问题发生的可能性。所以不能只考虑风险的单个因子。51Testing软件测试网s!zvK p9L9t2VS

'F~uWE(A.Y!i0　　steedhorse：如果能用20%的付出获得80%的测试覆盖率， 我觉得这是好事，而不是坏事。相对于不写单元测试，这也已经是不折不扣的“质的飞跃”了。然后，哪20%是可以牺牲的呢？我觉得错误处理就属于可以牺牲 的。很多时候错误处理的目标仅仅是fail fast，即让程序当场死掉，而不是带着错误继续运行，然后在其它地方莫名其妙地死掉。fail fast更多只是一种对待错误的策略，并不强求程序有确定的行为。所以我觉得在单元测试中这属于可以牺牲的部分。

　　姚若舟针对实际的情况，对以上微博做出回复：51Testing软件测试网 J8{ b"M GB0dC

J+Xnyjsc0　　回复@吴穹adam：就我提到的案例，代码行为我觉得比较适合在单元测试中覆盖，而且也比较高效。不知道分层测试的规划主要是指哪些方面？

$PB0WQ4q:ve0　 　回复@Robin圈：就我的案例来说，我觉得所谓添加测试价值不高更像是一种托词和惰性吧。其实，那些代码被使用的机会不是很极端，但是加测试需要做一 些隔离，甚至是一些代码抽象，所以就不愿意了。我很赞同TDD的观点，就是没有失败的测试，就不应该写出任何多余的代码来。51Testing软件测试网F*y@ Y(E$Jmq1X

　　回复@Ethan苏于登：我很认同。不过，这些改变或许要慢慢来吧。

　 　回复@林曙湧：我在写单元测试的时候，不会考虑加或不加某个测试的风险和危害有多大的。想到有必要的测试就加了，反正单元测试都很简单直接而且运行很 快。如果不加，一般都是被测试代码不需要的行为。如果单元测试充分的话，会使集成测试的数量大大减少。那时，根据风险评估来考虑如何添加测试，也许不再重 要了。

kl^9S(x0　　回复@steedhorse： 刚开始这样做，我可以理解。不过复杂的遗留代码系统中，大概没有什么错误处理的是可以fail fast。以后，还是应该尽量用测试来覆盖这些代码吧，不过牺牲他们了。

　　大家对这个话题进一步讨论：

　　吴穹adam：测试金字塔我认同的，单元测试应该多写，但还是要以风险为依据针对正确的单元来写出可维护的单元测试。

+iR5hafp0g)Ai"oWd0　　杭州李云：作为专业的软件开发工程师，那些边边角角一定要覆盖到，否则将大大降低单元测试的效果。这容易形成错误的推理：“单元测试因为边角不覆盖，所以测试效果不好；测试效果不好，所以单元测试效果不好；测试效果不好，所以单元测试不要那么认真。”51Testing软件测试网8^Q;A~/f^G|'V

　　@不许说话： 另外，按理说，单元测试是敏捷方法必备实践。而ACRD推行的scrum是敏捷方法的一种，自然必须首先符合敏捷的实践，然后才谈得上scrum。现在，scrum也几年了，敏捷实践呢？如果不能先一般性的敏捷实践，再scrum，我看着邪路就回不了头了。