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