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

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

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

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

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

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

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

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

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

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

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

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

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

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

推荐 rust