前端测试常见的 3 个误区

更新日期: 2022-05-27阅读: 933标签: 测试

前言

在做前端测试时,选用合适的测试策略远比一通猛狂测试更重要,所谓 “方向 > 努力” 。

如果选择了错误的测试策略,很容易写出维护性差和不稳定的测试用例。一旦业务出现变化,用例就全崩了。可能这也是大家讨厌写测试的原因之一吧。

Kent C. Dodds 在这篇文章 《Common Testing Mistakes 》 分享 了 3 个他看到的测试误区。今天,就把这篇文章分享给大家吧~

翻译中会尽量用更地道的语言,这也意味着会给原文加一层 Buf,想看原文的可点击这里


误区一:测试代码的实现细节

说实话,我非常喜欢这个误区( 详情可以看这里 ),因为在测试过程中,它是一个很严重的问题,这样写测试也不会带给你对应的信心。下面是一个测试代码实现细节的例子:

// counter.js
import * as react from 'react'

export class Counter extends React.Component {
  state = {count: 0}
  increment = () => this.setState(({count}) => ({count: count + 1}))
  render() {
    const {count} = this.state
    return <button onClick={this.increment}>{count}</button>
  }
}

// __tests__/counter.js
import * as React from 'react'

// 用 React Testing Library 是很难测代码实现细节的,所以这里用 enzyme 来测
import {mount} from 'enzyme'
import {Counter} from '../counter'

test('the increment method increments count', () => {
  const wrapper = mount(<Counter />)
  // 千万别这么做
  expect(wrapper.instance().state.count).toBe(0)
  wrapper.instance().increment()
  expect(wrapper.instance().state.count).toBe(1)
})

为什么说上面是在测代码实现细节?以及,为什么测代码细节是不好的呢?像上面那样过度测试实现细节会带来两个结果:

  • 我可以在测试完全通过的情况下弄崩业务代码 (比如在 onClick 赋值时故意写错变量名)
  • 我可以在重构业务代码的时候弄崩测试用例 (例如,把 increment 重命名为 updateCount ,测试就崩了,但业务代码是能正常运行的)

(译注:作者对重构的理解是:改动业务代码逻辑时,测试代码不应该做改动的, 因为业务逻辑没变,只是实现方式变了 )

类似这样的测试用例是最难维护的,因为你要不断地更新它们(基于上面第二点),同时,它们也不会给你带来更多代码的信心(基于上面第一点)。


误区二:100% 代码覆盖率

另一个误区就是强求 100% 的代码覆盖率。 有趣的是,我经常看到在一些项目里会被强制要求 100% 的覆盖率。不管这种规定是从哪来的,这其实都是对代码覆盖的误解,因为这样并不能给你带来相与之对应的代码信心。

代码覆盖只能告诉你一件事:

  • 这行代码有被测试用例跑过

然而,它没有告诉你的事有:

  • 代码是否按业务需求来正常工作
  • 代码是否能和项目里其它代码一起工作
  • 项目崩了的时候会发生什么(这里指意外崩溃)

代码覆盖率的另一个问题是:每增加一行代码的覆盖,整体覆盖量也会被增加。也就是说,如果你想提高整体覆盖率,那么在 “支付页” 添加测试和在 “关于” 页添加测试的效果是一样的(整体覆盖率变高了)。比这更严重的另一个问题是: 这样的覆盖率不能让你深入地了解你的项目...

目前来说,还没有一种万能的解决方案来获得准确的代码覆盖率,毕竟每个项目的需求是不同的。我一般不会过度关注代码覆盖率,而是更关注于项目里重要的部分是否覆盖到位。在确定项目中的关键部分之后,我会利用覆盖率报告来找出还未被测试覆盖到的边界情况。

声明一下,对于开源模块来说,100% 代码覆盖率是完全合理的,因为它们一般更容易达到 100% 覆盖率(项目不大,而且相对简单),而且他们都是很重要的代码,会被很多别的项目引用。


误区三:重复测试

相比于集成测试和单测,大多数人吐槽 E2E 最多就是很慢和不可靠。 你是不可能让单个 E2E 测试既能跑得快,又能像单测那样稳定的。反正就是不可能的。不过话说回来,单个 E2E 测试会比单测带来更多代码信心。在很多情况下,单测是不能像 E2E 那样带来那么高的代码信心的,所以项目中写点 E2E 测试是肯定值回本的!

当然,上面这么说不代表我们不能让我们的 E2E 测试跑更快和变得更可靠。其中,重复测试是人们写 E2E 测试时经常踩的一个坑,这会让降低整个测试的性能以及可靠性。

我们应该要在隔离环境下执行测试。 理论上,每个单独的 E2E 测试在执行时都应该像不同的用户使用软件一样。这样的话,每次跑测试都要走一遍注册登录流程来创建新用户了,对吧?看起来好像是对的,然后你每次就要点点按钮,输入用户信息来做注册登录。这么做只是为了业务中要用一下用户的登录态,是吧?错!这是不对的!

让我们回过头来想:为什么要写测试?因为这样你可以交付出更有自信、不容易崩溃的项目呀!假如,你有 100 个测试需要用已登录的用户来执行。那你应该要跑多少次注册/登录流程来让你相信代码是没问题呢?100 次还是 1 次?正常人都会选 1 次,因为只要 1 次成功,处处都应该成功。因此,剩下的 99 次额外的测试并不会给你带来任何代码信心。 它们只是在做无用功。

那你应该怎么做呢?既然我们已经搭建好了测试的隔离环境,那么就不应该在测试之间共享同一个 user 。 我推荐的做法是:当每次要注册和登录新用户时,在项目中发送同一个 HTTP 请求!发送请求肯定比在页面点击选中输入框和输入用户名、密码来得更快,而且会产生更少的假错误 (译注:假错误是指:测试失败了,但是其实应用代码本身没任何问题) 。只要你能保证有 1 个能完整跑通注册/登录的流程,那么你就不会失去这个登录注册流程的信心。


总结

一定要时刻记住我们写测试是为了提高代码信心。如果你现在做的事不能让你提高对代码的信心,那可以考虑你是否真的要这么做!

好了,这篇外文就给大家带到这里了。这篇文章主要列举了 3 个误区:避免过度测试代码细节、避免 100% 覆盖以及避免重复测试。这三个误区的产生都是因为我们没有搞清楚测试的本质:提高代码自信。当你很痛苦地编写测试用例的时候,那么很可能你钻入了牛角尖,往错误的方向写测试了,这时就要停止然后回过头来想:怎么做才能提高代码自信呢?

来源: 写代码的海怪

链接: https://fly63.com/article/detial/11610

测试工具比较:选Jest,不选Mocha

Jest的未来看起来非常令人激动!看到Jest推陈出新如此快速,我感觉它将很快成为整个React生态系统中大部分项目的首选工具。我建议,应该把测试迁移到Jest上去。

你需要了解的前端测试“金字塔”

如果您正在测试前端应用程序,则应该了解前端测试金字塔。在本文中,我们将看到前端测试金字塔是什么,以及如何使用它来创建全面的测试套件。

web网页性能测试工具都有哪些

作为前端开发,我们不仅需要满足产品需求功能的实现,同时也需要对自己做的网站进行安全、易用性、性能等方面的考虑。随着目前技术不断进步,web页面的性能测试工具也在不断完善,通过这些工具,我们可以客观的评价web网站的质量水平。

js单元测试工具-jest自动化测试

jest 是 facebook 开源的,用来进行单元测试的框架,可以测试 javascipt 和 react。jest 提供了非常方便的 API,可以对下面的场景方便的测试:一般函数、异步函数、测试的生命周期、react 测试

web测试要点、方法_web端测试大全总结

web测试大全,测试web网站有哪些点呢?主要包括:功能测试、兼容性测试、安全测试、输入框测试、用户权限测试等

前端性能测试工具整理简介_性能测试工具都有哪些?

前端性能测试工具都有哪些:Favicon、Open Graph、图片优化-压缩图像、CSS 优化-Autoprefixer、Purifycss、minify CSS、减少载入时间、GZIP、CDN、优化平台-Sentry、Google Tag Manager

不用写代码,也能做好接口测试

本文你将了解到:1、接口测试基本概念,包含什么是接口,什么是接口测试,为什么要做接口测试;2、接口测试用例设计,3、怎样不用写代码,也能快速的根据开发的API文档完成接口自动化测试脚本

Selenium打开浏览器加载慢的原因

在自动化元素定位操作中经常使用智能等待来加强定位的强壮性,主要就是因为WebDriver没有提供页面加载场景的方法;在使用JavaScript知识的突然心生灵感,可以使用JavaScript来配合验证页面加载,结果发现我真是井底之蛙。

power assert_更智能、优雅的全方位 assert 断言库

在写测试代码时,以往我们需要翻阅文档,学习各种 API 才能明白如何操作断言。而现在我们可以透过 power-assert 的 assert 方法来减轻调试压力。不仅如此,它还提供更加直观,具体的运行效果,帮助 DEBUG。写测试代码,其实可以很容易。

常用的web网站负载/压力/性能测试工具

在网站上线发布之前,我们除了必要的安全、功能测试外,往往还需要进行压力测试。通过模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件。包括:Apache JMeter 、LoadRunner、NeoLoad等

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!