各位是如何写单元测试的，如何保证单元测试覆盖率

事实上你要强行写的话，100%的覆盖其实都不算难事，但覆盖率只是单元测试其中一个评价维度。

很多时候应该看你的测试代码是否吻合一个合理的测试逻辑，比如写代码前画了一个流程图，你的测试代码就应该根据你的流程图去测试你的代码，这样你的测试代码才是可读可理解的，而不是根据你的代码里的 if-else/switch-case 去无脑的构造测试集来测试。

基本不写

核心链路 单测覆盖 80%就够了。

1. 基于意图测试
2. 代码设计的时候得有可测性。 虽然 tdd 和 bdd 很难推行就是了

我们之前用的 parasoft 测试覆盖率

写个毛的单元测试，库都是现成的测什么，接口吗，接口自己有单元测试他们为啥不测。。。

互联网大小厂这么多年，没见过有公司写单元测试的。

hooks 抽出来单元测试，基本覆盖率都能 90%以上
tsx 文件 render 出来都能 100%了吧

@maichael 因为项目团队要求要这样，有些逻辑尚未有好的解决方案来覆盖

@solaris2022 如果纯粹是为了代码覆盖率，你只要忘记代码的对应业务逻辑，纯看代码的逻辑来拼凑测试代码就好了，直接看代码测试覆盖来写测试代码，反正哪里没跑到就针对哪里写就行，很简单的。

干了快 6 年了, 接本都是被业务催着走
没写过单元测试

之前公司从不写单元测试，每次上线战战兢兢。后面在外企，必须写，真的有用，一大堆改动上线，真的就没问题，或者问题真的很少。而且感觉技术真的有进步。

想起 Linus 好像在哪说过类似的话，你们不能保证代码一次就 OK ，要写测试，除了我。不知道有没有记错

我们用 sonarqube ，其实实际意义不大，好多人为了覆盖率而覆盖率

怎么写（单元）测试？

要从可测的思考方式来书写代码， 才有“可能”写测试

在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了

要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试

知道哪些应该写， 哪些没必要

知道怎么结合 use case 来写

知道怎么结合 hook 在 commit 之前强制测试跑通

知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试

想到更多了在补充。

关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md

我只要求 80%的覆盖率, 持续集成的时候, 要求先过单元测试, 再发包.
非常稳健

我放 github 的 go 项目，按照单元测试报告一行行改就好了； go 没有 catry 不考虑，只要不是多进程功能基本都可以覆盖到。

在覆盖过程中，一些表达式错误和逻辑不可达都可以发现，简单错误都可以排除，剩下一般都是非代码逻辑错误。

有个很实际的问题就是业务不会给你那么多时间去覆盖单测，也许某个时期你能写，但某个时期开始就根本没时间写，然后慢慢的就废弃了。即便你硬着头皮写，你怎么控制住大家不要为了覆盖而覆盖写出一堆没用的东西，人性就这样

我只给复杂的逻辑, 比如订单 支付完成 重要函数写。

不过我的更像是 debug ，后面就不用了。

写什么单元测试？用户有问题会自己反馈 bug 来，用户就是最好的单元测试。 [dog]