React 现代化测试

更新日期: 2019-08-25阅读: 2k标签: 测试

测试的动机

测试用例的书写是一个风险驱动的行为, 每当收到 Bug 报告时, 先写一个单元测试来暴露这个 Bug, 在日后的代码提交中, 若该测试用例是通过的, 开发者就能更为自信地确保程序不会再次出现此 bug。

测试的动机是有效地提高开发者的自信心。


前端现代化测试模型

前端测试中有两种模型, 金字塔模型 与 奖杯模型 。金字塔模型摘自 Martin Fowler's blog , 模型示意图如下:


金字塔模型自下而上分为单元测试、集成测试、UI 测试, 之所以是金字塔结构是因为单元测试的成本最低, 与之相对, UI 测试的成本最高。所以单元测试写的数量最多, UI 测试写的数量最少。同时需注意的是越是上层的测试, 其通过率给开发者带来的信心是越大的。

奖杯模型摘自 Kent C. Dots 提出的 The Testing Trophy , 该模型是笔者比较认可的前端现代化测试模型, 模型示意图如下:


奖杯模型中自下而上分为静态测试、单元测试、集成测试、e2e 测试, 它们的职责大致如下:

  • 静态测试 : 在编写代码逻辑阶段时进行报错提示。(代表库: eslint、flow、TypeScript)
  • 单元测试 : 在奖杯模型中, 单元测试的职责是对一些边界情况或者特定的算法进行测试。(代表库: jest 、 mocha )
  • 集成测试 : 模拟用户的行为进行测试, 对网络请求、获取数据库的数据等依赖第三方环境的行为进行 mock。(代表库: jest 、 react-testing-library )
  • e2e 测试 : 模拟用户在真实环境上操作行为(包括网络请求、获取数据库数据等)的测试。(代表库: cypress )

越是上层的测试给开发者带来的自信是越大的, 与此同时, 越是下层的测试测试的效率是越高的。奖杯模型综合考虑了这两点因素, 可以看到其在集成测试中的占比是最高的。


基于用户行为去测试

书写测试用例是为了提高开发者对程序的自信心的, 但是很多时候书写测试用例给开发者带来了觉得在做无用功的沮丧。导致沮丧的感觉出现往往是因为开发者对组件的具体实现细节进行了测试, 如果换个角度站在用户的行为上进行测试则能极大提高测试效率。

测试组件的具体细节会带来的两个问题:

错误否定
错误肯定

以 轮播图组件 为例, 依次来看上述问题。轮播图组件伪代码如下:

class Carousel extends react.Component {
  state = {
    index: 0
  }

  /* 跳转到指定的页数 */
  jump = (to: number) => {
    this.setState({
      index: to
    })
  }

  render() {
    const { index } = this.state
    return <>
      <Swipe currentPage={index} />
      <button onClick={() => this.jump(index + 1)}>下一页</button>
      <span>`当前位于第${index}页`</span>
    </>
  }
}

如下是基于 enzyme 的 api 写的测试用例:

import { mount } from 'enzyme'

describe('Carousel Test', () => {
  it('test jump', () => {
    const wrapper = mount(<Carousel>
      <div>第一页</div>
      <div>第二页</div>
      <div>第三页</div>
    </Carousel>)

    expect(wrapper.state('index')).toBe(0)
    wrapper.instance().jump(2)
    expect((wrapper.state('index')).toBe(2)
  })
})

恭喜, 测试通过:white_check_mark:。某一天开发者觉得 index 的命名不妥, 对其重构将 index更名为 currentPage , 此时代码如下:

class Carousel extends React.Component {
  state = {
    currentPage: 0
  }

  /* 跳转到指定的页数 */
  jump = (to: number) => {
    this.setState({
      currentPage: to
    })
  }

  render() {
    const { currentPage } = this.state
    return <>
      <Swipe currentPage={currentPage} />
      <button onClick={() => this.jump(currentPage + 1)}>下一页</button>
      <span>`当前位于第${currentPage}页`</span>
    </>
  }
}

再次跑测试用例, 此时在 expect(wrapper.state('index')).toBe(0) 的地方抛出了错误:x:, 这就是所谓的测试用例对代码进行了 错误否定 。因为这段代码对于使用方来说是不存在问题的, 但是测试用例却抛出错误, 此时开发者不得不做'无用功'来调整测试用例适配新代码。调整后的测试用例如下:

describe('Carousel Test', () => {
  it('test jump', () => {
    ...

-   expect(wrapper.state('index')).toBe(0)
+   expect(wrapper.state('currentPage')).toBe(0)
    wrapper.instance().jump(2)
-   expect((wrapper.state('index')).toBe(2)
+   expect((wrapper.state('currentPage')).toBe(2)
  })
})

然后在某一天粗心的小明同学对代码做了以下改动:

class Carousel extends React.Component {
  state = {
    currentPage: 0
  }

  /* 跳转到指定的页数 */
  jump = (to: number) => {
    this.setState({
      currentPage: to
    })
  }

  render() {
    const { currentPage } = this.state
    return <>
      <Swipe currentPage={currentPage} />
-     <button onClick={() => this.jump(currentPage + 1)}>下一页</button>
+     <button onClick={this.jump(currentPage + 1)}>下一页</button>
      <span>`当前位于第${index}页`</span>
    </>
  }
}

小明同学跑了上述单测, 测试通过:white_check_mark:, 于是开心地提交了代码。结果上线后线上出现了问题! 这就是所谓测试用例对代码进行了 错误肯定 。因为测试用例测试了组件内部细节(此处为 jump 函数), 让小明误以为已经覆盖了全部场景。

测试用例 错误否定 以及 错误肯定 都给开发者带来了挫败感与困扰, 究其原因是测试了组件内部的具体细节所至。而一个稳定可靠的测试用例应该脱离组件内部的实现细节, 越接近用户行为的测试用例能给开发者带来越充足的自信。相较于 enzyme, react-testing-library 所提供的 api 更加贴近用户的使用行为, 使用其对上述测试用例进行重构:

import { render, fireEvent } from '@testing-library/react'

describe('Carousel Test', () => {
  it('test jump', () => {
    const { getByText } = render(<Carousel>
      <div>第一页</div>
      <div>第二页</div>
      <div>第三页</div>
    </Carousel>)

    expect(getByText(/当前位于第一页/)).toBeInTheDocument()
    fireEvent.click(getByText(/下一页/))
    expect(getByText(/当前位于第一页/)).not.toBeInTheDocument()
    expect(getByText(/当前位于第二页/)).toBeInTheDocument()
  })
})

关于 react-testing-Library 的用法总结将在下一章节 Jest 与 react-testing-Library 具体介绍。如果对 React 技术栈感兴趣, 欢迎关注 个人博客 。

原文:https://github.com/MuYunyun/blog/blob/master/React/测试/React现代化单元测试.md

链接: https://www.fly63.com/article/detial/4929

测试工具比较:选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等

点击更多...

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