大家的开发团队是否有单元测试编写规范？可否分享一下思路呢

[leonardyang]

从差不多正式接触编程开始就一直被灌输要养成编写单元测试的习惯，但是很遗憾目前工作的团队一直没有真正落地的单元测试编写规范，领导就硬性布置了一个 sonar 检测覆盖率达标任务，团队也一直没有投入精力设计制定一套规范或者约定，不知道大家的团队或者自己平时是怎么进行这个事的？

[williamfzc]

国内这个鬼环境，一推单测别人就会拿延期来威胁你，太绝望了..

[tabris17]

@williamfzc 简单啊，你把 unit test 计入 KPI 就行啦（啥？不算 KPI，那还写个屁

[guyeu]

主要问题还是需求三天一遍，代码推倒重来，单测的收益不够吧。。。像框架和工具类是应该覆盖单元测试的，业务代码我觉得没必要硬性要求，往往接口测试就足够了。

[justfortest]

主要是时间问题，时间充足肯定写测试，免去很多 bug

[index90]

单元测试覆盖率不达到 100%，无法合并到主干，我们已经做到了。

[RedisMasterNode]

@index90 单元测试覆盖率达到 100%印象中好像并不是什么推荐的实践？不过不太记得出处了，大意就是强制要求 100%实际上好像，比如说其实说明业务代码可能有一些 edge case 没有覆盖到的情况下就容易测试覆盖率 100%，当业务代码对各种边界条件处理都很完善的时候，想要 100%就很难了

[cwjokaka]

Postman 一把梭

[mitu9527]

单元测试还有规范么，顶一下，看看大家怎么说，学习一下。

[aviator]

目前我们公司没有做单元测试，都只是自己测一下接口。

[mitu9527]

最近我看了一点 TDD 和分层测试的文章，觉得这两个地方是单元测试落地的难点和重点。

[leonardyang]

@mitu9527 我之前也看了一些关于单元测试的论点，似乎良好的落地确实是需要测试先行的开发模式基础上

[index90]

@RedisMasterNode 我也向领导提过，当我的代码里出现“防御性代码”时，要覆盖它就变得非常困难，实际操作中，我可能为了避免写单元测试，把防御性代码撤销掉。
但 100%覆盖是“政治性”要求，没有商量的余地，而实际执行中，的确挺恶心。但也驱使着大家在写代码的时候，同时也思考着如何写出可测试的代码，间接地也提高了代码质量。实际上，我真的遇到了上面提到的“防御性代码”问题，但良心驱使我不能把这行代码删掉，解决的办法就是利用函数变量，在单元测试的时候把一些函数 mock 掉。

当然我们无法评价 100%覆盖所带来的价值，毕竟无法控制所有时空变量来比较，简单说，带来的价值无法量化，所以无法比较。

但从逻辑推理上说，还是有价值的，例如实施单元测试肯定对代码质量有所提升，我们重构的时候更加容易，合并主干的时候心里更有底气。

但我必须说，100%单元测试覆盖是一种倒逼行为，我们还需要正向的研发指导和程序架构设计，否者这个过程会很痛苦和很漫长。

[mitu9527]

@index90 不敢想象真的有人在追求 100%，你的领导是做技术出身的么？很好奇是什么驱使他作出 100%这个决策的。

[index90]

@mitu9527 我领导是技术出身的。我们经历了差不多两年的软件质量问题，我们尝试过各种方法去改善，我们还实施过 100%接口覆盖测试，但收效甚微。可能是因为走投无路了，什么方法都试一下，所以才决定试试单元测试这条路。

[index90]

@RedisMasterNode 我想补充一下，关于”100%印象中好像并不是什么推荐的实践？“

的确，如果你站在研发人员的角度上看。当如果站在研发管理角度上看，情况会变得不一样。
如果你是个人开发者，或者几个人的开发小组，你信任你的成员职业素质都很高，那么你是可以相信研发人员都在必要的地方加上了单元测试。
但是如果你管理的是几十人的研发团队，你会确信他们的职业素质都足够高么？他们中就没有一个人会因为偷懒，没有在必要的地方加上单元测试？如果你不要求 100%覆盖，那么就有了讨价还价的余地，90%？ 95%？ 99%？哪个才合适？无法拍脑袋定一个数。

那些”防御性代码“问题，只是极少概率事件，而且研发上也能用技术解决。但管理上可选择的余地并不比技术上多。

[b00tyhunt3r]

推荐 rust