フロントエンドユニットテスト&Mocha指北

ユニット-テストとは?

ユニットは、関数またはクラスなどの相対的に独立した機能モジュールである.完全なモジュール化されたプログラムは、多くのユニットで構成され、ユニットは自分のタスクを完了し、他のユニットとインタラクティブになり、プログラム全体の機能を完了する必要があります.

でテストして、テストです.

したがって、ユニットテストは、一般的には、プログラムの独立したユニットごとにテストされ、プログラムを構成する各モジュールの正確性を保証し、プログラム全体の正確な運行を保証することである.

なぜユニットテストを書くのですか?

ユニットテストはフロントエンドではあまり普及していません.最初はフロントエンドも「UI」に偏っていましたが、nodeの発展に伴い、「UI」ではないフロントエンドコードが増え、チームも開発に参加する人が増えています.システムが複雑になったり、あなたのブロックがnpmに提出されたりすると、間違いは基本的にGGになります.あるいはあなたはこのように考えて、テストは逃げられないで、devの上でテストして、prodの上でテストして、どのようにすべてテストしなければならなくて、その上毎回提出してすべてテストして、どうして自動テストを書かないのですか.私も多くのプログラマーが書き終わって走って見る習慣があると信じていますが、ユニットテストのロゴはconsoleに直接印刷され、コンパイルや梱包の時間も省け、皆さんの心理的なニーズ(わいせつな顔)を満たすことができます.一挙両得ですね.

この「Mocha」を乾かした

mochaはjsテストフレームワークであるほか、類似のテストフレームワークにはJasmine、Karma、Tapeなどがありますが、なぜMochaを紹介するのでしょうか.これしか分からないからです.コードをつける前に2つの概念を普及させなければなりません

BDD(Behavior Driven Development)BDDは行動駆動開発を意味し、敏捷なソフトウェア開発技術であり、具体的な内容はwikipediaの説明を参照してください.

Assertion断言は,コードの実行結果が予想と一致するか否かを判断し,一致しないと誤りを投げ出すことであり,簡単に言えばプログラムの真偽を判断することである.

例を挙げる

// add.js
function add(a, b) {
    return a + b
}
module.exports = add

通常、テストスクリプトはaddなどのテストソースと同名である.jsのテストスクリプトはaddです.test.js

// add.test.js
const add = require('./add.js')
const expect = require('chai').expect

describe(' ', function() {
    it('1 + 1   2', function() {
        expect(add(1, 1)).to.be.equal(2)
    })
    it(' Number', function() {
        expect(add(1, 1)).to.be.a('number')
    })
})

上のコードブロックはテストスクリプトであり、独立して実行することができ、テストスクリプトには1つ以上のdescribeブロックが含まれ、各describeブロックには複数のitブロックが含まれなければならない.describeはテストキットであり、この方法は2つのパラメータを伝達する必要があり、1つ目はテストキットの名前(' ')であり、2つ目は実行関数である.itブロックは試験例であり、単独の試験を表し、試験の最小単位であり、第1のパラメータは試験例の名前('1+1は2')であり、第2のパラメータは実行関数である.
その後terminalでmocha add.test.jsを実行する

$ mocha add.test.js

    
     √ 1 + 1   2
     √  Number
   2 passing (12ms)

add.jsを変えたら

// add.js
function add(a, b) {
    return a * b
}
module.exports = add

そしてmocha add.test.jsを実行します

$ mocha add.test.js

    
     √ 1 + 1   2
     1)  Number
   1 passing (8ms)
   1 failing

   1)    Number:
       AssertionError: expected 2 to equal 3
       + expected - actual

       -2
       +3

       at Context.it(add.test.js:6:27)

ここでは,どのテスト用例が間違っているのか,また間違っている位置が明らかであり,開発時に開発者が誤りを特定しやすい.

小結

上記の簡単な例から,mochaを用いた自動化テストの実現は簡単であることが分かる.前期開発ではユニットテストを書くのに少し時間がかかりますが、後で提供される利便性はそれを補うのに十分です.