前端TDD 与 BDD

一 TDD 基本流程

1. Header.test.js

it('header 包含一个input框', ()=>{

const wrapper = shallow(<Header/>)

const inputElem = findTestWrapper(wrapper, 'input')

expect(inputElem.length).toExist()

})

2.Header.js

classHeaderextendsComponent{

render(){

return (

<div><inputdata-test='input' /></div>

)

}

}

3. Header.test.js

it('header input 初始化应为空', ()=>{

expect(inputElem).toHaveValue('')

})

4. Header.js

classHeaderextendsComponent{

constructor(props){

super(props);

this.state = {

value: ''

}

}

render(){

const {value} = this.state;

return (

<div><inputdata-test='input'value={value}/></div>

)

}

}

5. Header.test.js

it('header input 用户输入时,变化', ()=>{

const userInput = 'learning jest';

inputElem.simulate('change', {

target: {value: userInput}

})

expect(wrapper).toHaveState({value: userInput})

expect(inputElem).toHaveValue(userInput)

})

6. Header.js

classHeaderextendsComponent{

handleInputChange = (e)=>{

this.setState({

value: e.targe.value

})

}

render(){

return (

<div><inputonChange={this.handleInputChange}/></div>

)

}

}

keyCode

it('input 输入回车时,如input无内容,无操作'), ()=>{

const fn = jest.fn()

wrapper.setState({value: ''})

inputElem.simulate('keyUp', {

keyCode: 13

})

expect(fn).not.toHaveBeenCalled()

}

it('input 输入回车时,如input有内容,函数被调用'), ()=>{

const fn = jest.fn()

wrapper.setState({value: 'learn react'})

inputElem.simulate('keyUp', {

keyCode: 13

})

expect(fn).toHaveBeenCalled()

}

TDD 优势 -- 代码质量高

单元测试 -- 测试覆盖率高 业务耦合度高

-- 代码量大 过于独立

  1. 先写测试再写代码
  2. 一般结合单元测试使用,是白盒测试
  3. 测试重点在代码
  4. 安全感低
  5. 速度快

函数库,UI组件库适合使用单元测试

业务代码更适合集成测试

二 BDD (Behavior Driven Developmen)基本流程

基于用于行为测试

  1. 先写代码在写测试
  2. 一般结合集成测试使用,是黑合测试
  3. 测试重点在UI(DOM)
  4. 安全感高
  5. 速度慢

tests/integration/TodoList.js

it('

1. 输入内容

2. 点击回车

3. 列表中展示用户输入的内容项

', ()=>{

const wrapper = mount(<TodoList/>)

const inputElem = findTestWrapper(wrapper, 'header-input')

const content = "aaa";

inputElem.simulate('change', {

target: {value: content}

})

inputElem.simulate('keyUp', {

keyCode: 13

})

const listItem = findTestWrapper(wrapper, 'list-item');

expect(listItem.length).toEqual(1);

expect(listItem.text()).toContain(content);

})

01 使用BDD测试redux

TodoList.js

exportclassTodoListextendsComponent{

//...

}

const mapDispatch = dispatch => ({

handleInputChange(value){

dispatch(actions.changeInputValue(value)

}

})

exportdefault connect(mapState, mapDispatch)(Header);

TodoList.test.js

import {Provider} from'react-redux';

import store from'../../store/createStore';

it('', ()=>{

const wrapper = mount(

<Providerstore={store}><TodoList/></Provider>

)

const inputElem = findTestWrapper(wrapper, 'header-input')

const content = "aaa";

inputElem.simulate('change', {

target: {value: content}

})

inputElem.simulate('keyUp', {

keyCode: 13

})

const listItem = findTestWrapper(wrapper, 'list-item');

expect(listItem.length).toEqual(1);

expect(listItem.text()).toContain(content);

})

三 TDD 理论

TDD过程

  1. 快速新增一个测试
  2. 运行所有测试,发现最新的测试不能通过
  3. 做小小的改动
  4. 运行所有测试,且全部通过
  5. 重构refactor代码,以消除重复设计duplication,优化设计结构

小实战 多币种资金

假设我们有这样一个报表

为了变成一个多币种的报表,加上单位

思考哪些测试一旦通过,就能说明代码正确地计算出报表呢?

  • 假设已给定汇率情况下,要能对两种币种的金额相加,并将结果转为某一种币种
  • 要能将某一金额(每股股价)与某一个数(股数)相乘,并得到一个总金额

为此,我们要创建一个to-do list以提醒我们需要做哪些事情,保持注意力,告诉我们什么时候可完工。

当法郎与美元利率为2:1时,5美元+10法郎=10美元

5美元*2 = 10美元

将amount定义为私有

Dollar 有副作用吗?

钱数必须为整数?

首先我们从测试开始。从简单的开始,清单中第二个不过是实现乘法功能,就从它开始。

const amount = 10;

let amount = 5 * 2;

将5*2移至times()中

let amount;

let times = ()=>{

amount = 5 * 2

};

如果你可以将代码分成一个个粒度比较小的任务,那么你自然可将它分得大小适当。但当你仅仅采用较大的步伐进行开发,那么你根本不会知道较小步伐是否合适。

let times = (amount)=>{

amount = amount * 2

};

let times = (amount, multiplier)=>{

amount = amount * multiplier

};

let times = (amount, multiplier)=>{

amount *= multiplier

};

现在第一个测试已经完成,回顾一下, 我们做了以下工作

  • 创建一个清单,列出我们所知道的需要让其运行通过的测试
  • 通过一小段代码说明我们希望看到怎样的操作
  • 暂时忽略细节问题
  • 通过建立存根stub来让测试通过
  • 逐渐使工作代码一般化,用变量代替常量
  • 将工作逐步加入计划清单,而不是一次全部提出

测试驱动开发总体流程如下

  1. 写一个测试程序,考虑你希望实现的操作要如何在你的代码中体现出来。你是在写story。设想你希望拥有的接口interface。在story中包含任何你所能想象到的、计算出正确结果所必需的元素。
  2. 让测试程序运行。尽快让测试可运行是压倒一切的中心任务。如明显存在整洁、简单的解决方案,那就键入。如果这个方案需耗费1分钟,那把它记下来,再回到主要问题点来,即怎样才能让测试在几秒内就能运行通过。(这种偏离审美的举动是难以理解的,但只是暂时的)
  3. 编写合格的代码。回归正派的软件设计之路。消除先前的重复设计、使测试尽快运行通过。

我们最终目标是整洁可用的代码。首先解决目标的“可用”问题,,然后在解决“整洁”问题。

尽快使测试可运行的三条策略中的两条:

  • 伪实现 - 返回一个常量并逐渐用变量代替常量,直至伪实现成为真实实现代码
  • 显明实现Obvious Implementation - 将真实的实现代码键入

我经常交替使用这两种实现模式,如果一切顺利,且我知道该写些什么,我会采用显明实现。一旦测试没有通过,我会退回转而采用伪实现,重构直到得到正确的代码。当恢复自信时,再次开始显明实现

首先我们讨论系统应当是这样还是那样工作。一旦就系统的行为达成一致,就开始谈论如何用最好的办法来实现它。

为了让测试能尽快工作,我们大量使用了丑陋的方法。现在是收拾烂摊子的时候了。

待续重构笔记

以上是 前端TDD 与 BDD 的全部内容, 来源链接: www.h5w3.com/28355.html

回到顶部