學習單元測試框架karma+mocha

tips: 最近在學習單元測試,選擇框架是自動單元測試karma+mocha。html

1、什麼是單元測試?

單元測試又稱模塊測試,是針對程序模塊(軟件設計的最小單位)來進行正確性檢驗的測試工做。程序單元是應用的最小可測試部件。 ———維基百科前端

如圖所示:
java

system: 全部組件的測試;node

integration:集成測試,多個組件一塊兒測試
git

component:組件的測試;github

functional:功能測試,比一個單元要大,比一個完整的組件測試要小。一般爲工做在一塊兒的的幾個方法/函數/類。上百的測試用例容許運行幾個小時。大部分功能測試是功能測試迴歸套件的一部分;npm

unit: 單元測試,可測試代碼的最小的一部分。一般是一個單一的方法,不會使用其它方法或者類。很是快;json


2、咱們爲何要學習單元測試?

咱們先來談談咱們工做中項目中遇到的問題吧!api

我總結了如下幾點:瀏覽器

1. 爲了驗證代碼的正確性。

2. 保證代碼的質量。

3. 高聚合,低耦合。


特地查了下知乎!!!

原文地址:www.zhihu.com/question/28…(爲何要學習單元測試)

以及下面這篇。


原文地址:taobaofed.org/blog/2016/0…(karma 的前生今世)。


3、karma框架

karma是一個測試runner,它須要測試框架。

1. karma 支持多種語言;

2. karma 支持多種測試框架;

3. karma 能夠模擬多種真實的瀏覽器環境;

4. karma 能夠監聽文件的變化;

5. karma 支持語法的預編譯。

對於前端而言,javaScript 和 node 就夠了。因此mocha 測試框架就夠了。同時mocha也能夠運行在瀏覽器上。對於mocha 而言,須要配置html,才能運行在各個瀏覽器上。配置mocha 相對複雜,繁瑣一點,因此咱們選擇框架是karma + mocha;


安裝配置karma;

1. npm install karma --save-dev

(當你安裝完karma 後,你就得相應的安裝karma所需的插件依賴。以下圖)


爲了不這種複雜的操做,以及後續的karma指令方便,建議全局安裝karma-cli;

npm install karma-cli -g


2.咱們能夠從新配置karma插件的依賴

karma init 


  1>. Which testing framework do you want to use ? (mocha)

  2>. Do you want to use Require.js ? (no) 

  3>. Do you want to capture any browsers automatically ? (Chrome,Firefox,Safari)

  4>. What is the location of your source and test files ? (test/**.js) 

  5>. Should any of the files included by the previous patterns be excluded ? () 

  6>. Do you want Karma to watch all the files and run the tests on change ? (yes) 

(配置完後,咱們能夠看到package.json 會自動生成依賴,以下圖,但只是生成依賴,還須要npm install 安裝到本地。)



四.認識mocha,斷言庫chai。

Mocha是一個可以運行在Node和瀏覽器中的多功能的JavaScript測試框架。

Mocha 同時支持TDD和BDD 2種測試接口模式。默認是BDD 模式運行。


什麼是TDD,什麼是BDD?

  • BDD: Behavior-Driven Development (行爲驅動開發)
  • BDD:行爲驅動開發是一種敏捷軟件開發的技術,它鼓勵軟件項目中的開發者、 QA和非技術人員或商業參與者之間的協做。主要是從用戶的需求出發,強調系統行爲。


  • TDD: Test-driven development (測試驅動開發)
  • TDD:測試驅動開發是敏捷開發中的一項核心實踐和技術,也是一種設計方法論。TDD的原理是在開發功能代碼以前,先編寫單元測試用例代碼,測試代碼肯定須要編寫什麼產品代碼。TDD的基本思路就是經過測試來推進整個開發的進行,但測試驅動開發並不僅是單純的測試工做,而是把需求分析,設計,質量控制量化的過程。


斷言庫的選擇?

  • should.js: BDD風格
  • better-assert: C語言,TDD風格
  • expect.js: should.js 的簡化版,BDD風格
  • assert:node自帶的斷言庫,TDD風格
  • chai: BDD/TDD雙模式,同時支持should/expect/assert

mocha 默認是BDD接口模式運行,若是須要TDD模式運行;

mocha -u tdd <test.js(測試項目)>複製代碼

(知乎BDD 和 TDD 的區別youtube上一些解釋)

咱們這裏不過多介紹mocha 和 chai 的相關知識,你們能夠關注

官方mocha中文翻譯chai api 中文文檔


5、寫測試用例

1. hello.js

/* test/hello.js */

var assert = require('chai').assert;
describe("karam start", function(){
    it("karma", function(){
        console.log('hello karma');
    });
});

/* 運行karma */

karma start複製代碼



2. 一個簡單的測試用例



需求:點擊這個紅色模塊的時候,背景顏色爲藍色。

/* page.html */

<body>       
    <div class="slider" onclick="changeColor(this)"></div>   
</body>複製代碼

/* page.js */

function changeColor(el){
      // 日常咱們只須要拿到dom對象,只須要操做一下就能夠實行背景顏色的變化;
      el.style.background = 'blue'

     // 若是寫測試用例呢?這部分是我我的寫的單元測試的方法。(我的理解)
     // var elClassName = el.className,       
     // addClassStr = this.addClass(elClassName,'sliderBlue');   
     // el.className = addClassStr; 
}

// 單元測試用例的方法
function addClass(classNameStr,newClass){       
    if(typeof(classNameStr) === 'string'){        
        var classNameData = classNameStr.split(' ');        
        if(classNameData.length>0){           
             if(classNameData.indexOf('sliderBlue') === -1 && classNameData.indexOf('slider')>-1){       
                 return classNameStr +' '+ newClass;        
        }else{               
             return classNameStr       
         }       
     }   
 }}複製代碼

有人確定會說,這種也須要些測試用例嘛?一行代碼的功夫。既然咱們要學習單元測試,那就用最小的例子來分析問題。若是這個事件,咱們須要寫單元測試呢?

而後咱們來看看寫斷言。

/* test/demo1.test.js */
import {expect} from 'chai';
import {expect} from 'chai';
import {assert} from 'chai';
var addClass = require('../src/demo1/page.js');
describe("顏色變化測試", function(){        
    it("顏色變化", function(){        
        var classTest = "slider",            
            changeClass = addClass(classTest,'sliderBlue');        
        expect(changeClass).to.be.equal('slider sliderBlue') 
        // assert 、 assert.ok 和 assert.equal 相同 ,都是==;       
         assert(changeClass == 'slider sliderBlue','slider和sliderBlue 等於 slider slderBlue')        
        assert.ok(changeClass == 'slider sliderBlue','slider sliderBlue')        
        assert.equal(changeClass,'slider sliderBlue') 
        // assert.strictEqual 是 === ;        
        assert.strictEqual(changeClass,'slider sliderBlue')   
     });
});複製代碼


6、最後總結

經過學習單元測試,能夠更加深入理解代碼的模塊化、解耦、穩定性,固然還有業務的架構,對於理解業務架構很是有幫助。簡直就是活生生的api 文檔。這就是咱們學習單元測試的目的。學習單元測試,能夠提高業務和代碼層的更深層理解和認識。

(題外話:固然並非全部的業務場景都須要用到單元測試,特別是業務常常變更的話,咱們能夠把單元測試用在那些常常用到的公共方法上,保證公共方法的穩定和低耦合。)


參考的一些網站,文檔:



我的項目代碼:github.com/yqzyou/test…

相關文章
相關標籤/搜索