-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
前端测试的那些事 #33
Comments
前言因为经常需要维护一些大型的业务项目和一些自己的开源项目,所以为了更好的“规范”代码质量和迭代的稳定性,开始写了一些单测。下面也主要是自己的一些总结吧,由于测试工具和框架很多,这里只介绍一些browser端常用的测试工具,文中如果有问题也欢迎拍正!!🙂 为何要测试之前我们开发项目的时候,总是会忽略去写一写单测,大多数原因可能是觉得没有时间或者是浪费时间。而且还需要去维护测试用例。 一些概念TDD (Test Driven Development)TDD 也就是测试驱动开发,简单的说,即在写任何功能代码之前,先写它的测试代码。具体步骤:
BDD(Behaviour Driven Development)BDD 即 行为驱动开发,可以理解为也是 TDD 的分支,即也是测试驱动,但 BDD 强调的是写测试的风格,即测试要写得像自然语言,运用一些比如 写法对比不管是 TDD 还是 BDD,我们来对比一些二者的写法: // TDD
suite('Array', function() {
setup(function() {
});
test('equal -1 when index beyond array length', function() {
assert.equal(-1, [1,2,3].indexOf(4));
});
});
// BDD
describe('Array', function() {
before(function() {
});
it('should return -1 when no such index', function() {
[1,2,3].indexOf(4).should.equal(-1);
});
}); 简单的看, BDD 风格写的会更容易理解,更加语义化。 断言(assert)在单元测试时,开发预计在程序运行到某个节点位置,需要判断某些逻辑条件必须满足,这样下面的一些业务逻辑才可以进行下去,如果不满足,程序就会"报错"甚至是"崩溃"。断言在单测中,也是主要用来确定某段程序执行结果应该是某个值这样的一个预期。 一些断言库的比较断言库即提供一套 API 帮助开发者在单元测试的过程中判定某个值是否符合预期,比如: should.js value.should.equal(1);
value.should.be.an.Object(); expect.jsexpect(value).to.be(1)
expect(value).to.be.an('object') chai
chai 提供了三种断言风格来分别适用于 BDD 和 TDD。 测试框架所谓"测试框架",就是运行测试的工具。通过它,可以为 Mocha
JasmineJasmine 不依赖于任何框架,所以适用于所有的 Javascript 代码。使用一个全局函数 describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
}); 前端测试工具相比于服务端开发,前端开发在测试方面始终面临着一个严峻的问题,那就是浏览器兼容性。前端开发中浏览器兼容性是一个永远的问题,而且我认为即使解决了浏览器的兼容性问题,未来在移动开发方面,设备兼容性也是一个问题。 所以在自动化测试方面也是如此,即使所有的单元测试集中在了一个runner中,前端测试仍然要面对至少4个浏览器内核以及3个电脑操作系统加2个或更多移动操作系统,何况还有令移动开发人员头疼的Android的碎片化问题。不过可以安心的是,早已存在这样的工具可以捕获不同设备上的不同浏览器,并使之随时更新测试结果,甚至可以在一个终端上看到所有结果。下面我们主要介绍 Karma KarmaKarma是一个基于 Node.js 的 JavaScript 测试执行过程管理工具(Test Runner)。该工具可用于测试所有主流Web浏览器,也可集成到 CI(Continuous integration)工具,也可和其他代码编辑器一起使用。这个测试工具的一个强大特性就是,它可以监控(Watch)文件的变化,然后自行执行,通过 Istanbul测试的时候,我们常常关心,是否所有代码都测试到了。
这个软件以土耳其最大城市伊斯坦布尔命名,因为土耳其地毯世界闻名,而地毯是用来覆盖的。 详细的文档参考阮老师的代码覆盖率工具 Istanbul 入门教程 动手!下面我们来搭建一个ES6 + jasmine + karma + Istanbul + webpack 的基础测试工具。 mkdir example
cd example
npm i babel-core bable-loader babel-preset-env --save 然后创建 {
"presets": [
"env"
]
} 接着我们需要安装 $ npm install karma --save-dev
$ npm install karma-jasmine karma-chrome-launcher jasmine-core --save-dev 接下来初始化 karma init 这样目录中便会多了一个 npm i webpack karma-webpack --save 接下来,就是我们熟悉的工作了,写一个加载测试脚本的 module.exports = {
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
use: {
loader: "babel-loader"
}
}
]
}
}; 再改写一下我们的 const webpack = require('../webpack.config')
module.exports = function(config) {
config.set({
basePath: '',
frameworks: ['jasmine'],
files: [
'test/**/*.spec.js'
],
exclude: [
],
preprocessors: {
'test/add.spec.js': ['webpack']
},
webpack: webpack,
reporters: ['progress'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['Chrome'],
singleRun: false,
concurrency: Infinity
})
} 当前我们的 npm install karma-spec-reporter --save-dev 然后加入 reporters: ['spec'] 其次我们需要添加 npm install babel-plugin-istanbul --save-dev 然后修改我们的 {
// ...
"env": {
"test": {
"presets": ["env"],
"plugins": ["istanbul"]
}
}
} 通过使用 npm install karma karma-coverage --save-dev 然后我们改一下
运行 npm run test 可以看到覆盖率的一些测试结果。但是这样有点不太方便,希望能可以直接在控制台输出就好了。所以我们需要改一下 coverageReporter: {
dir: './coverage',
reporters: [
{ type: 'lcov', subdir: '.' },
{ type: 'text-summary' } // 在控制台输出摘要
]
} 至此。已经完成了一个测试环境的搭建,可以满足大部分工程的单测配置。 结语可能平时由于大家更加关心业务代码,而会忽略一些前端的测试工作,网上的资料也是零零碎碎的,没有一个系统的总结和介绍。这里整理了一些测试工具的使用方法,希望可以对你有所帮助。然后本文所有代码和原始出处发表在个人博客中。也欢迎阅读之前的博文: 参考文章 |
学到很多了,谢谢分享 |
@ron0115 技术源于分享😎 |
thanks for qunzhu |
学习下 |
No description provided.
The text was updated successfully, but these errors were encountered: