// Source code -----------------------------
function add(x, y){
return x + y;
}
// helper ------------------------------------
var assert = function(expect, actual){
if(expect === actual){
return 'ok';
}else{
return 'ng';
}
};
// test ------------------------------------
var act = add(1,2);
assert(3, act); // -> ok
var act2 = add(1,'10');
assert(11, act2); // -> ng
単純なミスやロジック上のミスを発見することができる
網羅性のあるテストができる(しきい値、条件分岐、異常ケースなど)
別のロジックで書く、メソッド化、共通化、過分の削除、実行速度の向上(リファクタ)
テストしやすコード=よりよいAPI(I/F)をもったコードなので、利用しやすくみやすいコードが書ける
コードを追いやすくなる
テストコード自体が仕様書や使い方の説明にもなる
バグが減るので運用コストも下がる
→ No,機能間のテストやブラウザのチェック、ユーザビリティまではカバーできないので人の手でやるテストは必要。
→ (個人的には)しなくていいと思う。publicメソッドでカバーする
→ TDDでやった方がよいと思う。けど、ケースバイケースでいい
→ 100%目指す必要はない。
どこをテストしたかをわかるためで十分。
でも、カバレッジが上がることでもモチベーションはある
http://github.team-lab.local/ktsukuda/fe-study-testing
mocha + chai + sinon + enzyme + istanbul
Stack
mocha
chai
sinon.js
enzyme