JSTDD Intro for EVERY JavaScripters @kanazawa.js v1.7 (2012-03-31)

JSTDD Intro for EVERY JavaScripters 〜 4周⽬のTDDを始めよう〜

kanazawa.js v1.7 @wtnabe ⾦沢歌劇座 2012-03-31

Self-Introduction

Webの開発とシステム管理全般 Ruby, JavaScript, PHP kanazawa.js Certified Ruby Programmer Gold

JavaScriptの専⾨家 TDDの専⾨家

つまり皆さんと同じです

ちょっと違うこと以下は少なめ F5押して⽬を凝らす

今⽇はそのためのお話何を知り何を準備し⽇々どうしていくか

私とTDD 課題 2002年 XP, テストファーストを知る 2003年リファクタリングしたいテストないじゃん設計上⼿になりたいクソコードを紡ぐ不安

私とTDD テスト 2005年 Ruby, PHP でユニットテスト開始 2006年 JavaScriptでユニットテスト開始 WSH +
JScript + jsUnit

私とTDD インターフェイス 2007年『アジャイルプラクティス』「変更に強いコードとうまい設計を⽬指す覚え書き」 - あーありがち 2008年『インターフェイス指向設計』
『RESTful Webサービス』

私とTDD ⾃動化 2009年『Release It !』 Rake, Capistrano プロセス監視

私とTDD ⽂化 2010年 3⽉ TDDBC北陸 9⽉『レガシーコード改善ガイド』 12⽉ kanazawa.js v0.0.1
2011年 Rails 3 で TDD

私とTDD 2012年3⽉ kanazawa.js v1.7 ← イマココ

まとめると

設計は難しい http://www.flickr.com/photos/mrbill/3267227227/

⽬の前にはスパゲッティ http://www.flickr.com/photos/katiejean97/6966583763/

不安

http://www.flickr.com/photos/cauchipics/4444456369/ TDDを始めて

とってもハッピー ※ 不適切な画像は削除されました

以上、⾃⼰紹介おわり

本⽇のお品書き TDDってなに？テスティングフレームワークと関連知識やってみよう JavaScript TDDの課題 TDDの始め⽅（スピリチュアル注意）

本⽇のターゲットとりあえずJavaScript書いて動かせる⼈ TDD始めたい⼈

覚えてほしいこと Red / Green / Refactoring Firebugだけではつらい⾃動テストで安⼼を⼿に⼊れよう

What is TDDってなに？

だいぶ乱暴な説明

テスト駆動開発 Test-Driven Development テスト - テストコードの実⾏によって駆動 - 頑張りやすくする開発
- 開発⼿法

テストコード？プログラムをテストするプログラム

プログラムをテストするプログラム？

こんな感じ function isOdd( num ) { return num % 2;
} function testIsOdd() { console.log(true === isOdd( 3 )); console.log(false === isOdd( 2 )); } testIsOdd();

実⾏結果 $ node /path/to/test_code.js true true

あとでもうちょっと詳しく

詳しい⼈向けの諸注意 TDDのテストは開発者が⾃らのために⾏うテストです TDDはあくまでDevelopmentであってTestではありません

どうしてプログラムでテストするの？

Firebugじゃダメなの？

Firebugじゃダメなの？「確認」のくり返し正確さ？変更 → 全部やり直し⾒ていないところは？

Firebugはダメじゃない Firebugだけでやるのは⼤変

コンピュータは疲れを知らず同じことを正確に延々くり返せる

だからテストコード

では次に

得られるメリット現場で困っていそうなこと

困っていませんか？ console.log(), var_dump(), p, ... 間違ってそのままcommit/deploy

困っていませんか？デザイン vs Viewのコードシステム vs DOMのロード

困っていませんか？ライブラリのバージョンアップ機能追加気づかないところが壊れてた

困っていませんか？以前作ったコード仕様書 vs 実際の動作何が正しいのか？

TDDでこうした課題に⽴ち向かいやすくなります

その理由は？開発の進め⽅が違います

これまでの開発⼿法(1) コードを書き倒す祈る (-⼈"- ; ｳｺﾞｹ! 実⾏ orz

これまでの開発⼿法(2) 実装が済んでからまとめてテストテストは基本的に⼿動

これまでの開発⼿法の問題デバッグは祈りと⽬⼒⽬⼒頼みテスト開始が遅い遅い → バグや仕様漏れの発⾒も遅い遅いテストは疲れる疲れる

後半しんどすぎる

TDDによる開発の流れプログラムをテストする⼩さなコード実⾏ → 失敗成功するまでプログラムを直す以上を⼩さく素早くくり返す

TDDで問題を解決⼿動テストのくり返しで疲れる → ⾃動化⾃動化テストを始めるのが遅い → テストファーストテストファースト「待ち時間」
→ インターフェイスを決めて並⾏作業インターフェイスを決めて並⾏作業

もう⼀度コードを⾒てみる

プログラムをテストするプログラム function isOdd( num ) { return num % 2;
} function testIsOdd() { console.log(true === isOdd( 3 )); console.log(false === isOdd( 2 )); } testIsOdd();

こんなコード公開する？プロダクトコードとテストコード混在 JavaScriptの容量増加テストに⽤意するデータ丸⾒え

無理でしょ

そこでフレームワークですよ！

Testing Frameworks and knowledge around there テスティングフレームワークと関連知識

フレームワークってなに？テストの記述テストの実⾏

頻出ワード実⾏環境ブラウザなど組み込み / node.jsなど種類ユニット / インテグレーションスタイル
xUnit / BDD

今回は実⾏環境ブラウザブラウザなど組み込み / node.jsなど種類ユニットユニット /
インテグレーションスタイル xUnit / BDD

今回はブラウザユニットテスト

ユニットテスト主にメソッドやクラス単位で⾏うテスト

メソッド function method() { ... }

クラス function klass() { ... }

おんなじだ！

JavaScriptでは functionに対するテストと思っていいです

なぜユニットテスト？ JavaScriptだけで話が完結するすぐにでも始められる ← 重要 cf. JavaScriptのテスト事情-ダイジェスト版- 2011年10⽉13⽇

どんなものがあるの？ Jasmine ( 44% ) QUnit ( 41% ) via
http://dailyjs.com/files/DailyJSSurvey2011.pdf ※ 複数回答なので合計は100%以上

今回はQUnit

QUnitの理由準備が少ない記述が少ないつまりコードをスライドに載せやすい ※ 実務ではまた別な理由があると思います。

というわけでブラウザで QUnitを使ってユニットテスト

Try it ! やってみよう

最速QUnit解説

HTMLを⽤意 qunit.jsとqunit.cssを読み込む

<!doctype html> <html> <head> <link href="./qunit.css" rel="stylesheet" <script src="./qunit.js" type="text/javasc
</head> <body> <h1 id="qunit-header">QUnit example</h1> <h2 id="qunit-banner"></h2> <div id="qunit-testrunner-toolbar"></div> <h2 id="qunit-userAgent"></h2> <ol id="qunit-tests"></ol> <div id="qunit-fixture">test markup, will </body> </html>

プロダクトコードとテストコードも⾜す ... <head> <link href="./qunit.css" rel="stylesheet" ty <script src="./qunit.js" type="text/javascri
<script src="./product.js" type="text/javasc <script src="./test_product.js" type="text/j </head>

ファイルの状態 . ├── index.html ├── product.js <- プロダクトコード ├── qunit.css
├── qunit.js └── test_product.js <- テストコード

テストの書き⽅ test('テストの名前', function() { ... });

今⽇使うAssertion ok( 確認したいコード ); equal( 確認したいコード, 期待する値 );

これだけ

組み合わせるとこう test('isOdd', function() { ok( isOdd(3) ); });

さて

サンプルを⽤意しました a) 奇数判定 b) ⽇付の整形

a) 奇数判定確認したいこと TDDの教科書的な流れ

a) 奇数判定設計奇数を与えたら true が返ってくる偶数を与えたら false が返ってくる

TDDの教科書的な流れ Fail it - まず失敗 - Red Fake it -
仮実装 - Green 三⾓測量 & Refactoring

by @t_wada 何かに似てる

Diagram by Karn G. Bulsuk

⼩さく進める間違った⽅向に進んでないことを確認するためにわざと間違えるすぐにチェック（テスト）してフィードバックを次のサイクルに

Fail it 1 プロダクトコードのないテスト test('isOdd', function() { ok( isOdd(3) );
});

Fake it 1 内容のないプロダクトコード function isOdd( num ) { return
true; } test('isOdd', function() { ok( isOdd(3) ); });

Fail it 2 通らないテストパターン function isOdd( num ) { return
true; } test('isOdd', function() { ok( isOdd(3) ); ok( !isOdd(2) ); // new ! });

Fake it 2 Fail 回避 function isOdd( num ) {
if ( num == 3 ) { return true; } else if ( num == 2 ) { return false; } } test('isOdd', function() { ok( isOdd(3) ); ok( !isOdd(2) ); // new ! });

Refactoring 異なる⽅向からの2つ以上のテストこれらを元にゴールをより正確に計るこれが三⾓測量三⾓測量できたらリファクタリング

つまり今がチャンス！ function isOdd( num ) { return num % 2;
// Refactoring } test('isOdd', function() { ok( isOdd(3) ); ok( !isOdd(2) ); });

もう⼀度おさらい Fail it - まず失敗 - Red Fake it -
仮実装 - Green 三⾓測量 & Refactoring

テストコードは設計を表す test('isOdd', function() { ok( isOdd(3) ); ok( !isOdd(2) );
});

サンプル a) 奇数判定 b) ⽇付の整形⽇付の整形

b) ⽇付の整形確認したいこと変化するものはひとまず固定してテスト設計のbreak downが⼤事設計 Date → 「YYYY/MM/DD」な⽂字列

Fail it test('formatDate', function() { equal('2012/02/14', formatDate(new Date('Tue Feb 14
2012 1 });

ちょっと確認したいことが function formatDate( date ) { return [date.getFullYear(), date.getMonth() +
1, date.getDate()].join('/'); }

Failed Expected: "2012/2/14" Result: "2012/02/14" Diff: "2012/2/14" "2012/02/14" // あ

Dateのメソッドは桁数が合わない場合も

設計やり直しメソッドを分割する Date -> YYYY/MM/DD 数字の桁数を2桁に正規化する 2 -> 02 sprintfやstrftimeがあれば…。

さらに設計数字の2桁への正規化？ 2 -> 02 12 -> 12 110 ->
? 2012 -> ?

さらに設計今回は⽇付の処理に特化⽉、⽇に3桁以上の数字はあり得ない整数以外もあり得ない

Fail it test('padZero', function() { equal('02', padZero(2)); });

端折って本実装 function padZero( num ) { return '0' + num;
}

Fail it 2 test('padZero', function() { equal('02', padZero(2)); equal('12', padZero(12));
// new });

頑張る function padZero( num ) { var str = num.toString();
if ( str.length < 2 ) { return ('0' + str); } else { return str; } }

Refactoring function padZero( num ) { var str = '0'
+ num; return str.substr(str.length - 2, 2); }

完成テストコード test('formatDate', function() { equal('2012/02/14', formatDate(new Date('Tue Feb 14 2012
1 }); test('padZero', function() { equal('02', padZero(2)); equal('12', padZero(12)); });

完成プロダクトコード function formatDate( date ) { return [date.getFullYear(), padZero(date.getMonth() +
1), padZero(date.getDate())].join('/'); } function padZero( num ) { var str = '0' + num; return str.substr(str.length - 2, 2); }

⽇付の整形のまとめ「今」はテストしにくいので固定設計重要 / 場合分け重要 TDDそのものとは異なる経験も⼤事

Promblems of JavaScript TDD JavaScript TDDの課題

できないこと⾒た⽬の雰囲気効果の雰囲気 ※ レイアウトはすごく頑張れば可能

⼯夫すればできること処理が複雑頑張って分ける頑張って分ける

⼯夫すればできることまとめて読み込むと動かない名前空間を分けるどうしてもダメな部分はHTMLに直接適切な分割には経験が必要です。

名前空間 var Namespace = { ... } HTML <script type="text/javascript">
... </script>

⼯夫すればできること DOM操作ばかりで結局⽬視要素の有無や数を数えることは可能 ※ 不安がなければテスト不要

⼯夫すればできること無名関数ばかりできるだけ名前を付けよう即時実⾏無名関数だらけできるだけ避ける。中⾝は⼩さく。

無名関数 func1( function() { ... }); 名前付き func1( function() {
func2(); }) function func2() { }

(function() { ... })(); 中⾝をちゃんと外に (function() { func1(); })(); function
func1() { }

諦めも肝⼼根本的に不可能なテストや現時点で無理なテストはある別な⽅法を考えよう

How to Start TDDの始め⽅

できることからやる TDDは⼩さなくり返しその導⼊が最初から完璧だなんて不⾃然まずは現状の「困った」を⼀つでも解決

できる⼈を探そう分かってそうな⼈、頑張ったら分かりそうな⼈に⽚っ端から声を掛けよう

うまくいかないかもお前は最初から⼀⼈で⾃転⾞に乗れたのか？

はじめよう

例え失敗しても今動いているコードはなくならない

今やり直せよ。未来を。詠み⼈知らず

もう⼀つ

TDDがすべてではない我々の⽬的は何か？より良いプロダクトで顧客、ユーザーにより⾼い価値を届けること

そのためにやれることをやるだけ

TDDは⼤事な⼿段の⼀つ

最後にもう⼀度

覚えてほしいこと Red / Green / Refactoring Firebugだけではつらい⾃動テストで安⼼を⼿に⼊れよう

Any Questions ? Thanks to developers of testing frameworks, TDD
evangelists and prcatitioners and panelists And You

JSTDD Intro for EVERY JavaScripters @kanazawa.js v1.7 (2012-03-31)

JSTDD Intro for EVERY JavaScripters @kanazawa.js v1.7 (2012-03-31)

More Decks by wtnabe

Other Decks in Programming

Featured

Transcript