一般而言我们若不借助工具开发者工具做测试的话,会采用以下几种测试方法
为了方便我们新建一个文件夹用来存放此次测试的文件:mkdir API-testing
。
1.常规测试
cd API-testing
后新建一个文件。math.js
1 | module.exports = { |
上面编写完我们需求测试的函数功能后紧接着我们根据需求来新建另一个文件来进行常规测试,改功能模块是否符合达到自己需求的标准。simple.js
1 | /*常规测试用法*/ |
这样测试不仅效率低、成本高、而且耗费时间长。
2.内置模块assert
由于此次测试依旧使用上面math.js
文件这里就不过多复写了。
官网内置API
simple.js
1 | const assert = require('assert'); |
不显式的显示正确还是错误,这样不利于维护
3.chai模块
由于属于第三方模块所以我们需要先安装一下:npm install chai --save
。
具体模块详细使用参考官网
由于此次测试依旧使用上面math.js
文件这里就不过多复写了。simple.js
1 | const {should, expect, assert} = require('chai'); |
chai模块是不错的选择,但是这样手动写是非常凌乱的,所以需要借助
mocha
来管理。
4.mocha
诞生于2011年,是现在最流行的JavaScript测试框架之一,在浏览器和Node环境都可以使用。
所谓”测试框架”,就是运行测试的工具。通过它,可以为JavaScript应用添加测试,从而保证代码的质量。
mocha旨在帮你跑各种各样的断言库,mocha本身是不包含断言库的。
在使用之前我们先安装一下:npm install mocha --save
。
1 | module.exports = { |
mocha.js
1 | const {should, expect, assert} = require('chai'); |
cmd下使用mocha mocha.js
即可测试结果。
或者自行在package.json
中scripts:"test": "mocha mocha.js"
,后使用npm test
即可测试。
5.测试覆盖率
本次使用测试工具为istanbul
旨在测试代码使用覆盖率。它使我们能够更轻松地测试跨耦合模块的API更改。这是一个用JS编写的JS代码覆盖率工具。
使用npm install -g istanbul
安装好测试工具。
在package.json
中scripts
插入下面语句后npm run cover
即可测试
- Linux中使用插入
"cover": "istanbul cover _mocha mocha.js"
- Window中使用插入
"cover": "node_modules/mocha/bin/_mocha test/mocha.js"
math.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27function min(a, b){
const c = 3;
return (b - a) * c;
}
module.exports = {
add:(...args) => {
return args.reduce((prev, curr)=>{
return prev + curr;
})
},
mul:(...args) => {
return args.reduce((prev, curr)=>{
return prev * curr;
})
},
cover:(a, b) => {
if (a > b){
return a-b;
}else if(a == b){
return a+b;
}else{
return min(a, b);
}
}
}
function a(){} //不调用mocha.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35const {should, expect, assert} = require('chai');
const {add, mul, cover} = require('../math.js'); //#注1
describe('#math', () => {
describe('add', () => {
it('should return 5 then 2 + 3',() => {
expect(add(2, 3), 5);
});
it.skip('should return -1 then 2 - 3',() => { //only(仅测试这条),skip(跳过)
expect(add(2, -3), -1);
});
});
describe('mul', () => {
it('should return 6 then 2 * 3',() => {
// expect(mul(2, 3), 5); //测试时这样写也能通过????,不是等于6吗
expect(mul(2, 3)).to.be.equal(6); //一定要这样测试
});
});
describe('cover',() => {
it('should return 1 then cover(2, 1)',() => {
expect(cover(2, 1)).to.be.equal(1);
});
it('should return 3 then cover(1, 2)',() => {
expect(cover(1, 2)).to.be.equal(3);
});
it('should return 4 then cover(2, 2)',() => {
expect(cover(2, 2)).to.be.equal(4);
});
})
})注1:测试过程中
./math.js
将相同代码放在与mocha.js
同一文件夹并不会显示测试覆盖率,只有将math.js
文件放在上级目录后../math.js
调用才能显示代码覆盖率…懵。
npm run cover输出:
1 | Statements : 100% ( 14/14 ) |
其在当前目录下也会生成一个coverage
目录
6.持续集成
持续集成是一种软件开发流程,他有俩个特性:
- 频繁地将代码集成到主干
- 每次集成都通过自动化的构建来验证
持续继承的优点:
- 及时反馈结果,尽早发现问题
- 防止分支大幅偏离主干
- 自动化代替上面的手工,工程师将更多的时间精力放在设计、需求分析、风险预防等方面;
获得版本测试图标
首先必须先使用下面账户同步项目。选择打开需求的项目
必须git账户同步
图标获得
接着在项目本地新建本件.travis.yml
内容
1 | language: node_js |
最后将1-4步骤的项目git上github。即可通过查看在网上的自我build
测试信息。(必须先在查看上启动项目名才行)
等待时间测试的6、7、10版本没有通过点击build jobs
查看具体错误信息。
测试通过后选取通过图标的编码,这里选择markdown格式:
1 | **图注1: ** |
获得测试覆盖率图标
测试通过后使用git账户登录代码覆盖率图片链接选择相应项目后修改.travis.yml
1 | language: node_js |
将代码覆盖率图片链接的Settings——Badge同样复制markdown格式图片。
接着将上面图注1:以及以上获得的图片粘贴至本地项目的README.md
文件去。
最后重新git push提交即可看到自己项目中新增的俩个图片
若是图片显示未知,可以将链接的Settings——General——Default Branch——更新图片状态即可在github项目中查看图标了。
图标1是编译测试通过了node 8以及10版本可以使用; 图标2则是显示代码覆盖率
做完上面这些主要是你下次git push项目后,其版本测试以及代码覆盖率的图标会自动生成相应比率图。
7.基准
基准用于测试频繁使用的API接口的速度,从而选择更优秀的接口。
fn.js
1 | module.exports = { |
benchmark.js
1 | const {num1, num2} = require('./fn.js'); |
$node benchmark.js //测试结果Fastests is parseInt,表示parseInt比Number速度更快
本章测试属于API测试范畴