前端测试的反模式 | IDCF

一、过于关注实现细节的测试

在为前端项目编写测试用例的时候,你也许和我一样,曾遇到过以下困扰:

  • 明明进行了功能正确的改动,测试却挂了。修复测试有时候得认真阅读各种mock的细节,或者去了解很多本没有必要知道的代码逻辑。最后修测试花的时间比进行业务改动花的时间还要长(甚至长很多)。
  • 对代码进行提取抽象之后,为各个组件或函数添加测试,实际上是用测试工具的API去重复业务代码的内部实现逻辑(有时候还很麻烦!)。任何正常的重构都会导致测试失败,你本来希望测试能告诉你什么样的修改是对的,结果现在测试只能告诉你代码确实有被修改。
  • 测试写好,覆盖率提高,本应信心十足地认为代码变得健壮了,可是扪心自问,你知道自己写的这个测试弱点在什么地方,或者说还有多少细节没有涵盖。你精心模拟了一个条件,去触发逻辑流程,并且测试通过,可是在真实的浏览器交互中用户也许并不能触发这个条件。因此,同样的道理,你在自己的代码通过了他人写的测试之后,也不能确定真实场景下没有问题,只好把后续的重任交给QA。

造成上面三个问题的原因不止一个,但测试过于关注实现细节在我看来是最主要的。

  • 第一个问题,明明是正确的改动,可是测试不止是验证业务功能,还对实现细节提出了不该提出的要求,比如要求你的函数接受跟以前一样的参数,返回值必须是字符串而不能是数组等等。可是这个函数只是实现流程中一个小小的环节,也许在下次重构时就会不复存在。
  • 第二个问题很类似,如果测试代码去重复实现细节,不管进行正确还是错误的重构,你都得把测试改一遍,那原先的测试又能提供什么价值呢?
  • 第三个问题有时发生在,测试的实现细节,不能覆盖整个真实交互流程的时候。用户点击的是屏幕上的button按钮,而测试的起点是onClick事件被触发。后面的逻辑被验证成功,可问题偏偏发生在点击环节,真实的点击也许因为按钮状态而无法触发onClick事件。

因此,才会有人提出前端的测试应尽量去模拟真实的用户行为,Testing-Library就在其官网的“指导原则”章节,鼓励使用者尽量仿照应用真实的使用方式去编写测试,并明确提出,你的测试越接近用户的真实使用方式,它就能给你越多的信心。换句话说,你的测试应该尽量少用函数去手动触发,而要尽量多地利用测试框架给你的API,去模拟Input框的输入,按钮的点击,表单的提交等等。

如此一来,有的函数,你也无需写测试证明它的返回值如你所愿,需要写的,是页面显示了期待的文字,发生了预期的变化,进行了对应的跳转。你会发现,这时的测试就像写在卡里的AC一样。只要测试是通过的,你就有理由相信主体功能没有破坏,而不只是函数工作正常。

二、没有独立业务含义的测试单元

看到上面的方案,你可能会立马会想到一些问题。

首先就是测试流程可能会很长,从用户填完表单,点击提交,到期待的变化出现,当中可能经历了好几个函数的执行,连带着一系列的副作用。模拟这一系列行为,似乎是集成测试与E2E测试该干的事情。如果项目中大部分逻辑都是由这种测试去覆盖,看起来与测试金字塔所说的由单元测试作为地基是矛盾的。

我认为,当真实遇到的问题碰到了某种教条规范时,后者该适当地让步。

鼓励多写单元测试的原因在于它们成本低,有针对性。可是在前端项目里面,很多形式上的单元并没有独立的业务含义。

拿React项目举例,好多函数只是因为它们在形式上可以被抽取出来,就被拎到一个单独的文件里,从而降低主函数的复杂度。如果给它写单元测试,你就不得不手动触发它的参数变化,或者检测它的参数函数是否有被调用。

我们写的React hook尤其如此。很多时候抽取自定义的hook是出于逻辑上的原因,把相关的逻辑和数据聚合到一起,减轻UI组件的负担,但这些hook往往没有一个可以轻易解释清楚的业务含义,而且它们也不会被其它地方使用。

所以这类 “单元”只是长得像单元而已,它们其实只是一个实现环节。这里完整的UI操作流程,才更像一个有价值的单元,尽管它们在形式上可能超越了单个函数的范畴。

但我不想矫枉过正,确实有不少情况下,一个util函数,一个hook,一个很小的公共组件,都是有独立存在的价值的,因此,它们也应当被视为真正的单元,确实“有资格”拥有自己的专属测试。

testing-library下面有一个单独的库,叫react-hooks-testing-library,让你无需通过UI行为层面,而是直接以hook的方式去测试它们。它的GitHub页面上,明确提出了使用以及不使用它的场景:当你的hook不与组件强相关,拥有独立含义时可以使用;当你的hook只被一个组件使用,且和它的定义强相关时,则不建议使用。

插入一段:尽管存在react-hooks-testing-library这样的工具,但像SWR这样优秀的三方库,在用testing-library为自己的hook API做测试的时候,依然选择在UI层面进行。方法是,把自己的hook置于一个临时的div标签里进行render,把数据的变化映射成html文字的变化,最后对文字内容做断言。其实对于独立性强的函数,个人觉得放置在UI里面做测试倒没有太大区别,但SWR的例子体现了对“仿照真实使用场景去测试”这一原则的尊重。

将上面的规律套用到Angular项目中,也是类似的。对于独立性和通用性不强的pipe,directive,reducer,effect,service,都可以认为它们是实现流程的一部分,从UI行为层面写好测试即可。

总之,在构思前端测试的时候,与其死守“单元测试”的字面含义,不如结合实际场景,重新思考什么才是真正有价值的“单元”,因地制宜地去写。换种角度表述,与其在意我们写的测试是不是“单元测试”,不如追求更核心的东西——我们的测试有没有以合适的方式去校验逻辑。

另外,当我们的“单元”过大,一些逻辑可能就会覆盖不上。像sonar这类工具,不仅会检查你的行数覆盖率,还会检查你的各项条件语句是否有被测试执行。当一套测试的行为流程囊括了多个函数,而且每个函数都有好几个if…else语句时,想要在UI操作与mock数据上把所有情况都覆盖到,成本就会变得非常高昂。

对于此,我们得承认,无论用什么方式组织测试,覆盖所有的条件分支都是不太现实的,而且价值也不大。对于“满足条件A就执行XXX”之类的语句,条件为非A时没有业务上的规定,如果为了刻意覆盖函数的所有条件,就强行测它在非A的情况下返回一个undefined,则没有太多价值。对这类情况,用UI行为测试主要条件即可,如果你实在觉得有重要的逻辑没有被覆盖,不妨回过头来想想,是不是漏掉了某种输入条件,例如特定的用户键入或者特殊的API mock返回值。但是,当有过多的条件分支很难用业务场景去表述和模拟的时候,我们可能需要重新思考代码的实现逻辑是否合理了。

当然,即使按上面这样做,有时候还是会发现要覆盖的条件组合太多,从行为流程上写测试太复杂,这时就不得不做一定的妥协,为那些没有独立性的部分去单独写测试。如果这类测试不太好写,可以参照刚才提到的SWR官方测试用到的技巧,把要测的函数或者是对象放置在一个临时的UI组件下,以最小的成本做UI行为测试。

最后

总结一下上面谈到的几个原则:

  • 从真实用户的行为流程去测试,往往比测函数本身,能给你带来更多的信心。
  • 对于没有独立性和通用性的函数或对象,把它们视作实现的一部分,一般没有必要为它们去写单独的测试。不要拘泥于对“单元测试”的字面理解,不要被形式上的规律所束缚。
  • 不要把测试覆盖率视为太过重要的指标,它的目的还是帮助提升代码的稳定。有的代码没有覆盖也没关系,有的代码值得你覆盖好多遍。毕竟,我们不是为了写测试而写测试。
来源:Thoughtworks洞见
作者:钟立
声明:文章获得作者授权在IDCF社区公众号(devopshub)转发。优质内容共享给思否平台的技术同伴,如原作者有其他考虑请联系小编删除,致谢。

IDCF DevOps黑客马拉松,2021年度城市公开赛,11月6-7日,深圳站,企业组队参赛&个人参赛均可,一年等一回,错过等一年,赶紧上车~公众号回复“黑马”加入

你可能感兴趣的