我在现在的公司工作近半年了，公司的项目都需要写单元测试。但是写了这么久，感觉写单元测试费力不讨好，有时候写单元测试的时间大于写业务逻辑的时间，需要 mock 一大堆数据。要保证各种覆盖率，特别是分支覆盖率，需要覆盖到所写的每一个分支。
另外，大家写的单元测试质量参差不齐，因为感觉大家都是为了写测试而写测试，而不是真正的 tdd 。然而在迭代频繁，节奏紧凑的环境下，想要做到真正的 tdd ，还是有很大的难度的（个人觉得 tdd 实现需求会花更多的时间，可能是自己没正确认识和掌握 tdd?）。所以这就导致大家往往先去实现逻辑，再去写测试。
简而言之就是认为单元测试费时费力，又没有明显的收益，想请教一下大家怎么看待单元测试。
初次提问，如有不恰当的地方，请大家指出。
 |
101
caixiangyu17 Dec 15, 2021
@sulfoh6 你说的很有道理，很多公司也的确是这个样子。不过我还是觉得有一些方法是需要单元测试的，因为一个方法有可能需要处理很多不同的 input 。简单说，一个方法功能可以是很独立却很复杂。
举个例子，一个检查输入格式的方法，输入的用例可能有十几甚至几十种，但是其实返回就是一个 true/false 。这样的一个 validator 的类，可能 public 的方法只有一个，但是里面有很多 private 的方法，并且逻辑可能很复杂。这时候 unit test 就比较重要，因为很可能忘记一些 edge case 或者是增加一些需求。如果没有的话，一些相似的 input 很可能会被改坏掉。 同样，很多大学作业也是非常适合 tdd 。虽然大学左右有时候会脱离现实工作，但是又一些也是有一定代表意义的。如果你上过编译器的课，并且作业是真正去实现一个简单的编译器，你就会感受到，没有 unit test ，疯狂打补丁有多痛苦。 |
Select Language