enzymejest TDD与BDD开发实战

一、前端自动化测试需要测什么

1. 函数的执行逻辑，对于给定的输入，输出是否符合预期。

2. 用户行为的响应逻辑。

- 对于单元测试而言，测试粒度较细，需要测试内部状态的变更与相应函数是否成功被调用。

- 对于集成测试而言，测试粒度较粗，一般测试ui展示上的变更（文本内容改变、组件类别改变等）。

3. 快照测试。对于不需要经常修改dom结构的组件，我们会存储一个快照，如果在后续的版本中修改了dom结构，测试用例会不通过，需要确认更新快照。

二、为什么需要自动化测试

你或许会疑惑，如果我们做的是一些业务的开发，而不是工具类函数的开发，似乎手动测试就可以满足需求。对于用户行为的响应逻辑可以通过点击来测试，dom结构的变更也可以通过肉眼观察。测试用例的代码可能甚至比业务代码量大，那前端有必要耗时耗力的进行自动化测试吗？

长期来看，集成自动化测试是有必要的。

1. 有利于回归测试。在公司项目中产品是经常迭代的，当我们修改了A功能，就需要测试相关联的B功能不受影响。如果没有自动化测试，每一次回归测试都需要手动进行，且并不能保证你没纳入考虑范围的C功能是不受影响的。自动化测试有利于降低回归测试的成本，并提高程序员的安全感。

2. 有利于代码重构。跟上一点类似，我们需要保证重构前后的预期是一致的，这时候我们就可以先对于老代码编写测试用例，使测试用例能够全部通过。再重构业务代码，如果重构后的代码也能通过全部的测试用例，那么代码的可靠性是较高的。如果采用手动测试的方案，那么你的执行流可能是：重构A功能->测试A功能->重构B功能->测试A和B功能。因为重构前的代码架构通常会混乱一点，所以为了确保后重构的功能不影响先重构的功能，手动测试的工作量会越来越大。

3. 有利于代码优化。当测试用例通过后就可以放心的进行代码优化了，省去了每次代码优化完手动测试的成本。

4. 前端开发与后端接口解耦。假设后端接口还未开发完成，当我们和后端约定好数据结构后，就可以模拟后端接口返回的数据并进行测试。当然，我们也可以选择在业务代码里写死数据并进行手动测试，但这就意味着后续需要修改业务代码；或者选择用抓包工具模拟响应结果进行手动测试，这种不需要修改业务代码，但是需要权衡手动测试和自动化测试的成本。

三、TDD与BDD

测试驱动开发（Test-Driven Development）的流程如下：

1. 根据要实现的功能编写测试用例，测试用例不通过

2. 实现相关功能，测试用例通过

3. 优化代码，完成开发

由于测试用例不通过时会显示红色，测试用例通过后会显示绿色，所以测试驱动开发又称Red-Green-Development。

测试驱动开发的优点如下：

1. 实现代码前先编写测试用例，确保代码一定是易于测试的，在开发视角的基础上扩展了测试视角，代码的组织架构会更好。

2. 如果测试用例有误，可能在实现功能前后均可以通过测试。由于我们先编写测试用例后开发，如果测试用例在开发前就通过，那么大概率测试用例是有问题的，我们就可以及时发现修改。降低了编写出错误测试代码的可能性。

3. 自动化测试的通用优点。

行为驱动开发（Behavior-Driven Development）一般是测试驱动开发的自然延伸，它的核心在于根据用户行为来设计测试用例，对于是否需要在开发前编写测试用例没有强制要求。

四、单元测试与集成测试

单元测试的优点：测试粒度细，代码覆盖率高，运行速度快。

单元测试的缺点：

1. 代码量大。

2. 关注代码实现细节，与业务代码耦合度高。

3. 每个单元的单元测试通过，也无法保证集成后能正常运行。比如说A组件给B组件传入data，A组件测试传入的data结构为对象，B组件测试接收到的data为数组，两个组建的测试用例都能通过，但是集成后运行就会由于数据结构不一致报错。

单元测试的适用场景：工具库。

集成测试的优点：

1. 测试粒度没那么细，比所有单元的单元测试代码量总和小。

2. 不关注代码实现细节，只关心展示给用户的结果，业务代码耦合度较低。

3. 集成测试能确保单元能够协作运行，通过集成测试通常来讲系统对于用户能够正常运行。

集成测试的缺点：

1. 集成测试测试可能不如单元测试细致。

2. 集成测试需要运行多个组件，测试速度会慢一些。

集成测试的适用场景：业务系统。

五、具体实现

单元测试、集成测试、TDD、BDD之间要怎么集成其实没有标准答案，而且BDD和TDD本身也不是对立的概念。只是BDD本身是以用户的“故事”为导向的，这些故事通常涉及不止一个单元所以BDD通常和集成测试结合，单元测试与TDD结合。

1. 单元测试与TDD

用react脚手架创建出项目后，由于enzyme官方没有适配react17及以上版本，需要将react版本降级为16。如果需要用react17及以上的版本，可以用非官方的适配器，或者改用react-testing-library。但是react-testing-library本身不关注代码实现细节，而是以用户视角触发的，所以我个人感觉不是很适合做单元测试。

npm install react@16 react-dom@16 --save
npm install enzyme enzyme-adapter-react-16 --save-dev

我们做一个简单的todoList项目，当我们在输入框中输入内容，按下回车后就会展现在下方。点击项尾的删除键可以进行删除。

我们将这个项目拆分为Header组件和UndoList组件。

我们在src目录下创建如下结构，__tests__/unit目录下编写单元测试代码，TodoList目录下编写业务代码。

因为采用TDD的模式开发，所以先来编写测试代码。

环境准备

enzyme与react集成需要配置适配器，由于这个配置需要在每个测试文件最开始引入，所以我们可以将其抽离到一个单独的文件中，然后对jest进行配置，让jest在测试环境准备好后执行该文件。

react内部其实已经对jest进行了配置，我们需要做的就是将其暴露出来。

// npm run eject的执行前提是没有未追踪的文件，所以我们需要先初始化git仓库并提交
git init
git add .
git commit -m "init resposity"
npm run eject

在运行完npm run eject后，我们可以发现package.json文件有新增的配置项Jest，配置项中有一个属性是setupFilesAfterEnv。

  "jest": {
    // ...
    "setupFilesAfterEnv": [
      "<rootDir>/src/setupTests.js"
    ],
    // ...
  },

可以看出，setupTests文件会在测试环境准备好后执行，所以我们只需要新增文件setupEnzyme.js，修改jest配置项，并将enzyme的适配器配置填入该文件即可。

  "jest": {
    // ...
    "setupFilesAfterEnv": [
      "<rootDir>/src/setupTests.js",
      "<rootDir>/src/setupEnzyme.js"
    ],
    // ...
  },

// src/setupEnzyme.js

import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() });

由于jest本身不支持TextEncoder、TextDecoder、ReadableStream，而在enzyme内部又会调用到相应的方法，所以我们需要在import Enzyme前将方法挂载在global上。

// setupTests.js

import { TextEncoder, TextDecoder, ReadableStream } from 'util';
global.TextEncoder = TextEncoder;
global.TextDecoder = TextDecoder;
global.ReadableStream = ReadableStream;

测试用例编写

- Header

header组件的功能是点击回车键时，能将数据传送给TodoList，我们将header组件设计成受控组件（即组件内的状态会根据用户输入实时更新）。对功能进行拆解如下：

1. 输入框的展示值为state.inputData，state.inputData初始化为空。

2. input框输入内容时，state.inputData随之改变。

3. 当输入框不为空时，用户敲击回车后，调用props.addUndoItem，state.inputData清空。

4. 当输入框为空时，用户敲击回车后，不调用props.addUndoItem.

4. 快照测试。

test('输入框的展示值为state，state.inputData初始化为空', () => {
  const wrapper = shallow(<Header />);
  const input = wrapper.find("[data-test-id='input']");
  expect(input.prop('value')).toBe(wrapper.state('inputData'));
  expect(wrapper.state('inputData')).toBe('');
})

由于我们还未编写业务代码，运行npx jest时，测试用例是不通过的。

业务代码编写

由于enzyme只能追踪到类组件里的状态，所以这里我们创建类组件。

如果你需要用函数组件，可以参考Testing React Hook State Changes - DEV Community，他的核心思路是相信react，只要我们调用了setState方法，传入了正确的参数，就认为状态可以被正确的修改。通过mock setState方法，来判断调用了函数并传入了正确的参数。

import React, { Component } from "react";

export default class Header extends Component {
  state = {
    inputData: "",
  };
  render() {
    return (
      <div>
        <input data-test-id="input" value={this.state.inputData} />
      </div>
    );
  }
}

再次运行测试，测试通过。

然后是第2-4个测试用例及业务代码。

test('输入框输入字符时，state.inputData随之改变', () => {
  const wrapper = shallow(<Header />);
  const input = wrapper.find("[data-test-id='input']");
  const inputData = "hello world";
  input.simulate('change', { target: { value: inputData } });
  expect(wrapper.state('inputData')).toBe(inputData);
})

import React, { Component } from "react";

export default class Header extends Component {
  state = {
    inputData: "",
  };
  render() {
    return (
      <div>
        <input
          data-test-id="input"
          value={this.state.inputData}
          onChange={(e) => this.setState({ inputData: e.target.value })}
        />
      </div>
    );
  }
}

test('当输入框不为空时，用户敲击回车后，调用props.addUndoItem，state.inputData清空', () => {
  const func = jest.fn();
  const wrapper = shallow(<Header addUndoItem={func} />);
  const inputData = "hello world";
  wrapper.setState({ inputData });
  const input = wrapper.find("[data-test-id='input']");
  input.simulate('keyUp', { keyCode: 13 });
  expect(func).toHaveBeenCalled();
  expect(func).toHaveBeenLastCalledWith(inputData);
  expect(wrapper.state('inputData')).toBe('');
})

test('当输入框为空时，用户敲击回车后，调用props.addUndoItem，state.inputData清空', () => {
  const func = jest.fn();
  const wrapper = shallow(<Header addUndoItem={func} />);
  wrapper.setState({ inputData: '' });
  const input = wrapper.find("[data-test-id='input']");
  input.simulate('keyUp', { keyCode: 13 });
  expect(func).not.toHaveBeenCalled();
})

import React, { Component } from "react";

export default class Header extends Component {
  state = {
    inputData: "",
  };
  handleKeyUp = (e) => {
    if (e.keyCode === 13 && this.state.inputData !== "") {
      this.props.addUndoItem(this.state.inputData);
      this.setState({ inputData: "" });
    }
  };
  render() {
    return (
      <div>
        <input
          data-test-id="input"
          value={this.state.inputData}
          onChange={(e) => this.setState({ inputData: e.target.value })}
          onKeyUp={this.handleKeyUp}
        />
      </div>
    );
  }
}

header组件的逻辑编写完成，接下来我们补充完样式以后，就可以进行快照测试了。

先引入一下header。

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
ReactDOM.render(<App />, document.getElementById('root'))

// App.jsx
import TodoList from './container/TodoList';
export default function App() {
  return <TodoList />
}

// container/TodoList/index.jsx
import React, { Component } from "react";
import Header from "./Header";
export default class index extends Component {
  render() {
    return (
      <div>
        <Header />
      </div>
    );
  }
}

运行npm run start，页面展示如下。

我们对样式进行优化，优化后页面展示如下。

// container/TodoList/style.css

.header-wrapper {
  display: flex;
  align-items: center;
  justify-content: center;
  height: 100px;
  background-color: #e1d3d3;
  gap: 20px;
}

.header-input {
  outline: none;
  line-height: 24px;
  width: 360px;
  border-radius: 5px;
  text-indent: 10px;
}

.header-span {
  font-size: 24px;
  font-weight: bold;
}

// container/TodoList/Header.jsx
import React, { Component } from "react";

export default class Header extends Component {
  state = {
    inputData: "",
  };
  handleKeyUp = (e) => {
    if (e.keyCode === 13 && this.state.inputData !== "") {
      this.props.addUndoItem(this.state.inputData);
      this.setState({ inputData: "" });
    }
  };
  render() {
    return (
      <div className="header-wrapper">
        <span className="header-span">TodoList</span>
        <input
          data-test-id="input"
          className="header-input"
          value={this.state.inputData}
          placeholder="请输入待办项"
          onChange={(e) => this.setState({ inputData: e.target.value })}
          onKeyUp={this.handleKeyUp}
        />
      </div>
    );
  }
}

// container/TodoList/index.jsx
import "./style.css";
// ...

快照测试

test('快照测试', () => {
  const wrapper = shallow(<Header />);
  expect(wrapper).toMatchSnapshot();
})

运行测试用例后，会生成__snapshot__文件夹，后续修改样式/dom结构都会导致测试不通过。

剩下两个组件的流程不做赘述，编写完代码如下。

// __tests__/TodoList.js

import { shallow } from "enzyme";
import TodoList from '../../index';

let wrapper;
beforeEach(() => {
  wrapper = shallow(<TodoList />);
})

test('快照测试', () => {
  expect(wrapper).toMatchSnapshot();
})

test('state.undoList初始化为空', () => {
  expect(wrapper.state('undoList')).toEqual([]);
})

test('向header传入addUndoItem方法，当该方法被调用时，更新state.undoList', () => {
  const header = wrapper.find("[data-test-id='header']");
  expect(header.prop('addUndoItem')).toBeTruthy();
  expect(header.prop('addUndoItem')).toEqual(wrapper.instance().addUndoItem);
  const prevUndoList = ['hello'];
  wrapper.setState({ undoList: prevUndoList });
  const inputData = 'world';
  wrapper.instance().addUndoItem(inputData);
  expect(wrapper.state('undoList')).toEqual([...prevUndoList, inputData]);
})

test('向undoList组件传入list属性，属性值为state.undoList', () => {
  const undoList = wrapper.find("[data-test-id='undo-list']");
  expect(undoList.prop('list')).toBeTruthy();
  expect(undoList.prop('list')).toEqual(wrapper.state('undoList'));
})

test('向undoList组件传入deleteUndoItem方法，当该方法被调用时，更新state.undoList', () => {
  const undoListData = ['hello', 'world'];
  wrapper.setState({ undoList: [...undoListData] });
  const undoList = wrapper.find("[data-test-id='undo-list']");
  expect(undoList.prop('deleteUndoItem')).toBeTruthy();
  expect(undoList.prop('deleteUndoItem')).toEqual(wrapper.instance().deleteUndoItem);
  wrapper.instance().deleteUndoItem(0);
  expect(wrapper.state('undoList')).toEqual([undoListData[1]]);
})

// TodoList/index.js
import React, { Component } from "react";
import Header from "./Header";
import "./style.css";
import UndoList from "./UndoList";

export default class index extends Component {
  state = {
    undoList: [],
  };
  addUndoItem = (item) => {
    this.setState({
      undoList: [...this.state.undoList, item],
    });
  };
  deleteUndoItem = (index) => {
    const newUndoList = this.state.undoList;
    newUndoList.splice(index, 1);
    this.setState({ undoList: newUndoList });
  };
  render() {
    return (
      <div>
        <Header data-test-id="header" addUndoItem={this.addUndoItem} />
        <UndoList
          data-test-id="undo-list"
          list={this.state.undoList}
          deleteUndoItem={this.deleteUndoItem}
        />
      </div>
    );
  }
}

// __tests__/Undolist.js
import { shallow } from "enzyme";
import UndoList from "../../UndoList";

test('快照测试', () => {
  const wrapper = shallow(<UndoList list={[]} />);
  expect(wrapper).toMatchSnapshot();
})

test('props.list为空时，列表展示为空', () => {
  const wrapper = shallow(<UndoList list={[]} />);
  // console.log(wrapper.find("[data-test-id='list-item']"));
  expect(wrapper.find("[data-test-id='list-item']").length).toBe(0);
})

test('props.list为不为空时，列表展示对应项', () => {
  const list = ['hello', 'world'];
  const wrapper = shallow(<UndoList list={list} />);
  const listItem = wrapper.find("[data-test-id='list-item']");
  expect(listItem.length).toBe(2);
  expect(listItem.at(0).text()).toBe('hello');
  expect(listItem.at(1).text()).toBe('world');
})

test('点击删除按钮时，调用props.deleteUndoItem', () => {
  const list = ['hello', 'world'];
  const func = jest.fn();
  const wrapper = shallow(<UndoList list={list} deleteUndoItem={func} />);
  const deleteBtn = wrapper.find("[data-test-id='delete-btn']");
  deleteBtn.at(0).simulate('click');
  expect(func).toHaveBeenCalled();
  expect(func).toHaveBeenLastCalledWith(0);
})

// UndoList.jsx
import React, { Component } from "react";

export default class UndoList extends Component {
  render() {
    return (
      <ul className="undo-list-wrapper">
        {this.props.list.map((item, index) => {
          return (
            <li key={index} className="undo-list-item">
              <div data-test-id="list-item">{item}</div>
              <div
                data-test-id="delete-btn"
                className="undo-delete-btn"
                onClick={() => this.props.deleteUndoItem(index)}
              >
                -
              </div>
            </li>
          );
        })}
      </ul>
    );
  }
}

页面展示效果如下

我们运行npx jest --coverage来看一下测试覆盖率。

运行完命令后会新生成coverage文件夹，我们在浏览器打开index.html。

由于我们没给src/index.js和src/App.jsx编写测试用例，所以第一条显示为0。但是对于我们编写了测试用例的TodoList组件，可以看到测试的覆盖率是百分百，所以TDD这种开发模式的代码覆盖率是非常高的。

2. 集成测试与BDD

可以看出，在进行单元测试时，测试代码量是比较大的，如果单元内部的逻辑很复杂，那么测试代码量还会大幅增加。

而且，我们在单元测试中用了大量业务代码内的属性，像state、props等，这些其实对于用户来说是不可见的。那么，我们可不可以站在用户视角，以模拟用户行为的方式来进行黑盒测试呢？答案是肯定的。

站在用户角度，Todolist无非就干了三件事。

1. 待办项初始化为空。

2. 输入待办项后回车，待办项会被展示在最下方。

3. 点击删除按钮，对应的待办项被删除。

根据以上的用户故事，我们编写对应的测试代码。

import { mount } from 'enzyme';
import TodoList from '../../index';

let wrapper;

// 对于集成测试而言，我们需要渲染子组件，所以调用mount方法
// 对于mount方法，元素会被真正挂载在页面上，所以如果我们在两个测试用例里面分别创建了wrapper
// 且每个wrapper中有一个undoListItem
// 那么在不调用卸载方法的情况下，页面上会存在两个undoListItem
// 所以在集成测试里，我只创建了一次wrapper
beforeAll(() => {
  wrapper = mount(<TodoList />);
});

test(`
  1. 用户进入网站
  2. 待办项显示为空
  `, () => {
  const undoListItem = wrapper.find("[data-test-id='list-item']");
  expect(undoListItem.length).toBe(0);
})

test(`
  1. 用户输入待办项
  2. 用户敲击回车
  3. 待办项展示在下方
  `, () => {
  const input = wrapper.find("[data-test-id='input']");
  const inputData = "hello";
  input.simulate('change', { target: { value: inputData } });
  input.simulate('keyUp', { keyCode: 13 });
  const undoListItem = wrapper.find("[data-test-id='list-item']")
  expect(undoListItem.length).toBe(1);
  expect(undoListItem.text()).toBe(inputData);
});

test(`
  1. 用户输入待办项
  2. 用户敲击回车
  3. 在原待办项下方新增待办项
  `, () => {
  const input = wrapper.find("[data-test-id='input']");
  const inputData = "world";
  input.simulate('change', { target: { value: inputData } });
  input.simulate('keyUp', { keyCode: 13 });
  const undoListItem = wrapper.find("[data-test-id='list-item']");
  expect(undoListItem.length).toBe(2);
  expect(undoListItem.at(1).text()).toBe(inputData);
});

test(`
  1. 用户点击第一项的删除按钮
  2. 第一项被删除
  `, () => {
  const deleteBtn = wrapper.find("[data-test-id='delete-btn']");
  deleteBtn.at(0).simulate('click');
  const undoListItem = wrapper.find("[data-test-id='list-item']");
  expect(undoListItem.length).toBe(1);
  expect(undoListItem.text()).toBe("world");
})

test(`
  1. 用户点击第一项的删除按钮
  2. 第一项被删除
  `, () => {
  const deleteBtn = wrapper.find("[data-test-id='delete-btn']");
  deleteBtn.at(0).simulate('click');
  const undoListItem = wrapper.find("[data-test-id='list-item']");
  expect(undoListItem.length).toBe(0);
})

因为我们已经实现了对应的业务代码，所以测试用例均可以正常通过。

可以看出，相比较对于一个个单元进行单元测试，整体编写集成测试的代码量是会更少的。如果后续我们修改了state里的数据结构，或者是props的属性名，只要最终展现在页面上的结果不变，那么集成测试都可以通过。