Skip to content

无测试,不代码 —— mocha前端测试框架使用详解 #18

@EchoFUN

Description

@EchoFUN

当大神们吹嘘着“无测试,不代码”的时候。
很多前端或许会感到不屑。也许会认为,写测试用例只是出于对自己代码的不自信,或者是为了炫耀自己的多牛逼(看我的代码还有测试用例!)
首先,为什么前端要写测试用例?

从我自己的开发经历看来。
1. 写测试用例能更迅速定位浏览器的兼容问题
哈哈
浏览器之间的兼容,是一个谁都不想却又必须得面对的问题。
就像便秘一样,偶尔来这么一次,痛不欲生,我猜你也不会是因为便秘拒绝便便的。
所以你会怎么做,硬着头皮继续上。
如果你坚持认为,你有jquery,prototype.js,moontools在手,可以秒杀一切这类问题的同学,可以略过这篇文章了。
这类框架解决的,只是前端基础性质的兼容问题,并且在这基础上扩展了一些编程的规范和工具。像是dom ready的检测,remove child等等一系列历史遗留问题。
但是据我所知,这些框架,目前还么有提供像localstorage的兼容,storage/onstorage事件的监听的兼容之类的一些现代浏览器新特性和老版本的浏览器之间冲突的解决方案。
很明显,框架的更新,总是滞后于浏览器版本的迭代带来的新特性的。自从chrome和ff化身版本帝之后,这样的问题愈发凸显明显。
所以,我们当使用了这些新特性,并且在用javascript在老版本的浏览器上模拟了这些新特性的时候。很有必要使用一套完整的测试用例,确保在每个浏览器中你的代码能准确无误的运行。
so,我们怎么做呢?
(写单元测试!)
哎呀,没错,都会抢答了!
2. 方便了整个前端工程的可持续发展
恩,可持续发展。大家应该都很熟悉。不光大佬们这么讲,我们也是需要提倡,哈哈。
在前端工程越来越庞大的同时,模块之间的关系越来越复杂。
试想这样的场景,团队中的小A修改了某个非常通用的底层模块,那么基于了这个模块的所有上层模块是否都能正常工作呢?
恩,这种情况下如果你还是会一个个手动的在不同的浏览器下点击测试,那也就活该每天会加班到天明了。
如果在最初对这个模块使用的地方都写了测试用例,放在浏览器中跑一遍便知道了效果。
3. 看起来好像很牛逼的样子!
难道不是吗?哈哈。

扯了这么多,让我进入主题。
为什么会选择moncha,只是因为是TJ大神写的... ... 用了很多他的东西,比较有情切感而已。

npm install -g mocha

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions