ユニットテストで人生に勝利する by Mark Story
ユニットテストは開発の中で大事なプロセスです
ユニットテストは手動でクリックするようなテストと違い
自動化されたテストです
今日は僕がどうしてユニットテストをしているか
また実際のテストの方法についてお話しします
テストしづらい部分をテストする方法や
テストを最新の状態に保つ Continuous Integration についてもお話します
大学を出てすぐにプログラミングを始めました
お金が必要だったので（笑）
CakePHPを使って2年半になります
DebugKit や ApiGenerator などのプラグインを作りました
普段は FreshBooks で働いています
オンライン上で請求書を発行するようなサービスで
そこではリードデベロッパをしています
ユニットテストは僕を素晴らしくしてくれるのでしょうか？
激しくその通りです
何故ユニットテストをするのでしょうか
余分な時間は掛かりますが、その他のコードが正しく動いているのを確認する為です
特に後になってから起きた問題を修正する時間を削減するのが主な理由ですね
何かを変更した後にそれまで動いていた部分が動いている事を確認する
何かを変更して動いていた物を壊してしまった事はある人はどれくらい居ますか？
(挙手多数)
テストを書けばそういう事は起きません
バグを見つけたらその部分のテストを書けば
同じバグが発生する事はありません
またユニットテストは複雑なコードの設計の助けにもなります
プログラムをシンプルな部品に分割する
例えば「CMSを作れ」という素晴らしいチケットがあった時
細かいテストにブレークダウンして
テストを一つづつパスさせれば、何かが動いた事になります
またテストは生きたドキュメントにもなります
内容を忘れてもテストを見ればわかります
また問題を早めに見つける事もできます
何か変なものをコードに入れてしまってもすぐにわかります
コードの確実性を高める事もできます
とにかく知っている範囲で動くようにテストを書きます
クリックしながらテストをすると3時間かけても 自分の所では動いたと思うとしか言えません
でも僕らには自動化された殺人兵器があります
自動化されたテストの利点はまさに自動化されている事です
CIもできますし、テストを素早く実行できます
変更をする度に5時間かけてクリックするのではなく
ボタンをクリックするだけで何か失敗していないかやきちんと動いているかが確認できますね
テストできるものは全てテストするべきです
夜中に問題を起こしそうなコード
問題が起きる恐怖を軽減する為にテストを書きましょう
また金銭に関わるようなコードにもテストを書けばユーザーやあなたが金銭を失わないようにできます
また以前にも問題が起きた壊れやすいコードにもテストを書きましょう
また手動でテストしにくいものにもテストを書きます
PDFの生成のように時間がかかる部分にテストを書いた事があります
またテストには異なる種類があります
ユニットテストと機能テスト、結合テストです
ユニットテストはアプリケーションの細かい部分のテスト
オブジェクトやメソッド、関数単位で正しい結果を返しているかなどをテストします
また多くの場合モックを使います これはテストしづらい部分をテストするのにとても便利です
テスト駆動開発をする際にもユニットテストは便利です
テスト駆動開発ではコードを書く前にテストを書きます
テストを書いて コードを書いて またテストを書いてコードを書く その繰り返しですね
テストが失敗するようなコードを本番環境向けに書かない
僕は普段、コードを書いてそれからテストを書きます
そしてテストが壊れないように余分なコードを消します
機能テストは部品が一緒にうまく動作するかをテストします
上位のオブジェクトから部品が正しく動いているかをテストする
例えばCakePHPもModelが変更されたら結合テストを行う
あなたが書いたコードだけなく データベースと通信する部分などが正しく動いている事をテストする
機能テストは比較的時間がかかります
多くのリソースやデータベースを使うからです
さらにはリモートのサービスを実行したりもします
ユニットテストは基本的に1つのクラスのテストです
細かい部品ごとに正しい動作をテストする
それをまとめてに行うのが結合テストです
テストをする時にはいくつかの課題があります
ちょっと水を飲みます
話すのが速すぎるかな？ 大丈夫？
まずはテストを書くのに時間がかかる事
しかし同じバグを何度も修正するのはもっと時間がかかります
正しいテストを書けば同じバグはもう起こりません
テストは問題がある事しか証明しません
問題が無い事は証明しません
1つテストがあるのはバグが無いという意味ではなく、1つのバグがテストされたという事にしかなりません
またユニットテストはテストがある部分のエラーしか見つけられません
コンピューターはテストがある部分だけテストします
なのでありえるパラメータ範囲などもテストを書かないといけません
テストの利点はなんでしょうか
余分な手間が最初にかかりますが、問題を早く見つける事ができます
QAテスターや上司がクリックして「どうして壊れてるんだ」と聞かれる前に問題を見つけられます
またテストのプロセスを自動化する事が出来ます
自動化はすばらしいです フレームワークも色々な事を自動化してくれますが テストはもっと自動化してくれます
またユニットテストは結合テストに発展させる事もできます
セレニウムのスクリプトを書いてコンソールから
ブラウザでクリックするようなテストを実行できます
これはほんとに素晴らしいです
決められた仕様をテストにすれば
テストがパスすれば仕様を満たせている事が確認できます
以上でテストの素晴らしさの賞賛は終わりです
次にモックオブジェクトの話題
モックオブジェクトはテストしづらい部分をテストする際にとても便利です
個別のテストを書きづらい時にモックオブジェクトを使えば簡単になります
オブジェクト同士を呼び合わないようにテストさせる事ができます
オブジェクトがそれぞれ間違った方法で呼び出し合って
テストが失敗するのを防げます
またモックは実装前にオブジェクトの振る舞いを確認する助けにもなります
例えば何かのサービスにPOSTして結果を配列で返すようなクラスの場合
例えばそのサービスが友達のジョーが書くとしたそれがどうなるのか予測できません
必要な配列を返すモックがあればジョーの方で問題があっても関係ない
ジョーの部分が終ったらジョーがその部分に対してテストを書けばよい
そうすれば僕はジョーの所で何をやっているかは知らなくても大丈夫
モックをグローバル関数やグローバルなスコープで読み込まれるファイルに使えるでしょうか？
使えません
モックを使うにはクラスになっていて、処理がメソッドの中にある必要があります
モックはどういう時に使うべきでしょうか？
モックは外部と通信するようなコストが高かったり 危険の大きい時に使うのがベストです
テストを実行する度に顧客にEメールを送信なんて事ありえないよね（笑）
メール送信処理はサーバーとの通信などのコストも高い
そういった外部依存を少なくする
TwitterやPaypalなどと通信する部分にモックを使うのもパーフェクトな例
Twitterが落ちてしまうとコードが壊れていないのにテストが失敗してしまう
この部分にモックを使っておけばTwitterが落ちても開発を継続できる
また落ちた事が無いようなサービスにモックを使っておけば
そのサービスが落ちてしまった時に自分のコードに何が起きるのかを知る事ができる
例えばPaypalが落ちた時にコードが爆発してしまうのか そのまま動いてしまうかは知っておくべきだ
ユニットテストとモックを使えばこういった事態を想定できる
またユニットテスト中で不必要に大量にディスクに書き込みをしてしまう場合もモックにできる
データベースもご存知の通り遅いのでモックにできる
データベースに /dev/null でも使ってない限りはね (笑)
/dev/null はWEBスケーラブルだ (有名なジョーク)
データベースへの書き込みは遅くてコストかかるのでモックを使えばたくさんのテストを実行するのに便利だ
本当にデータベースに通信しなければいけない場合は別だけど 大抵の場合はそうじゃないね
クラスが２つある場合 それぞれが正しく呼び出し合っている事を確認することになる
その場合にスタブとしてモックを使う事ができる それぞれが期待する動作をモックに実装する
期待しないパラメータが呼び出されたらテストが失敗するようにしておく
そうやって問題の範囲を絞って
個別のコードが動くために必要な部分をスタブ化して扱いやすくする
そうすれば問題を分離できる
例えばこのメソッドがNullを返すとエラーが起きる時に
ファイルがおかしい時にNullになるなんて時にモックを使ってテストすれば問題を分離できる
どうやってモックを作るか
モックにするには依存関係を実行時に変更できる必要がある
僕が使っている3つの方法はコンストラクタ渡しとファクトリーメソッドとセッターメソッドだね
それぞれの例ではPHPUnitのモックを使っているけど質問があれば聞いてください
コンストラクタ渡しはJavaなんかで古くから使われている依存関係の処理で
依存するクラスのオブジェクトをコンストラクタで受け取るようにする方法だ
このCarクラスの場合はエンジンとドライバーのオブジェクトをコンストラクタで受け取っている
モックを使いたい時はエンジンやドライバーのモックオブジェクトを変わりに渡せばいい
次はファクトリーメソッド
ファクトリーメソッドはサブクラスでモックを返すようにオーバーライドすればいい
このRaceCarクラスはエンジンのオブジェクトをgetEngineメソッドから取得する
モックを使う場合はgetEngineメソッドを別のオブジェクトを返すようにオーバーライドすればいい
さらに別の方法がセッターメソッド
フレームワークやツールでよくあるようにsetやgetでオブジェクトを操作する方法だ
これなら簡単にオブジェクトを入れ替える事ができる
GiantEngineを入れ替えたければsetEngineを使える
モックはテストの目的によっては重要になる
モックやスタブで危険なオブジェクトやメソッドをテストから除く事ができる
モックを使ってオブジェクトが他のオブジェクトを正しく扱っているかを確かめられる
この例ではgetMockメソッドでモックを取得し
何かしら危険なtypeメソッドをスタブ化している
最初はjsonのパラメータが渡され 次の例ではxmlのパラメータが渡されている事をチェックしている
RequestHandlerオブジェクトが正しく動いていればテストはパスするはず
テストの中でオブジェクトを作る時にモックを作り 期待するパラメータごとの結果をスタブ化する
これはCake2の実際のテストの例だけど
危険な処理のスタブ化
ヘッダーの送信の処理は危険な処理だ
外部のサービスに通信する処理もそうだし
呼び出しの度に課金が発生するようなサービスをテストの度に呼び出すのはよくないやりかただ
そういった場合にスタブを使えばいい
さっきのやり方と同じでヘッダを送るメソッドをスタブ化している
statusCodeメソッドが呼び出された場合は301
headerが呼び出された場合はLocationとURLの２つのパラメーターが渡る事を期待している
どうしてスタブ化するかというと オブジェクトがheader関数を呼んでしまうからだ
スタブ化しないで実行してしまうとテストの度にcakephpのサイトを見る事になってしまう
モックを使ってテスト時に起こる良くない現象を解決している
コストのかかる処理のスタブ化
このCampainMontiorは遅いので隠してしまおう
幾つか連絡先の情報を作っておいてモックを作り
このメソッドが呼ばれた時はこのデータが返ってくるとみなす
DependencyInjectionでこのクラス全体を置き換える事もできるけど
モックを使って自動的にメソッドが呼ばれた時の戻り値を設定してる
わかるかな？
この場合だとonceなので2回呼び出された場合はテストが失敗する
厳密に数値ごとの結果を定義してテストを失敗させることもできる
このセクションのまとめ
モックはテストを素早く実行させたり、テストの事前事後の処理を少なくする事ができる
外部サービスを呼ぶような場合もスタブ化してしまえば
本当の意味でのユニットテストが実行できる
重要なところをテストして余分なものを分離する
以上でモックの話はおわり
もちろんSimpleTestにもモックオブジェクトはある
コアクラスのテストケースを見れば大量にモックを使っているのがわかると思う
自動殺人ロボット
人体模型でも出来る自動テストだ
実行されていないテストは消していい
こういう場合ビルドサーバーを建てよう
Hudsonはとても使いやすいJava製のビルドサーバーだ
たくさんのプラグインがあってメールを送ったり、Jabberにメッセージを送ったりできる
テストがコードをどれだけカバーしているかのカバレッジレポートを出すこともできる
テストを毎晩とか毎時とか毎日にスケジュールしたり、ポストコミットのフックを設定もできる
起動したHudsonはコードをチェックアウトして
さらにスクリプトを実行してテストを行う
SvnでもGitでも使える
MercurrealやBazarも大丈夫 使わない理由はないね
一般的なのはコミットやプッシュの度にテストを実行する
短い間隔でジョブを待機させてテストする
開発が進んでない場合も夜間にテストを実行する
サーバーが空いている時にカバレッジレポートを出力する
Hudsonのセットアップは今見せようと思ったけどネットワークがおかしいみたいで
夕べやったやつをお見せします
wgetでダウンロードしてjavaコマンドで実行する
ターミナルの大きさお変えて
Hudsonのディレクトリを開く
見えるかな？
Hudsonは他のJavaプログラムと違ってコンテナやTomcat無しで
5000の依存関係をコンパイルしたりしなくても
1ファイルをダウンロードして実行できる
インストールに何時間もかかってTomcatを入れてなんて
事も前にあったけど
これでローカルでHudsonが動いている
localhostの8080にアクセスして
おっと
(.comを指摘されて)みなさんのほうが賢いみたいだ
これが僕のマシンの上のHudson
この画面でHudsonの管理ができる
ビルドの履歴をプロジェクトリストから見たり
最後にテストが失敗したか成功したかが見れる
これはプロジェクトの例
テストのプロジェクトを作ってみよう
フリースタイルプロジェクトを選んで
gitリポジトリを使う
このブランチを使って
手動でビルドしたり定期的にビルドしたり SCMから呼ばれたりもできる
実行するシェルの設定
cakeのコンソールを使ってテストを実行
コアのヘルパーのテストを実行するようにする
メールの送信を設定
誰かメールを受け取りたいかい？
誰もいない？ じゃあグラハムだ
ビルドが失敗する度に君にメールを送る
ビルドを壊した人にメールを送るなんてのもあるね
これでプロジェクトは設定できた
これでビルドが失敗するとすぐに「マークがビルドを失敗させた」と周知する事ができる
これで壊した人が責任をもって直すようになるね
実にすばらしい
ビルド中だね
♪
Hudsonには複数のプロジェクトを作成できる
Hudsonはリポジトリからローカルにコードを持ってきて
指定されたコマンドを実行する
cakeコマンドとか必要なら他のコマンドも先に実行できる
そして最後のコマンドのexitステータスが失敗ならビルドは失敗した事になる
exitステータスが成功ならビルドも成功
コンソールのアウトプットを見てみよう
githubからクローン中だね
時間がかかりそうだ
(ネットワークが不調)失敗しそうだ
ビルド失敗だね
1分前に失敗 グラハムにはメールが届くはずだ
設定を変更
(ローカルのリポジトリに変更)
これで動くかな
ディレクトリ名で動くらしい グラハムによると
実行中だ
ネット接続が面白い事になってるね
失敗だ
ネットワーク接続があればなー
遅いな
やっぱり繋がってないな
本来ならここにビルド成功を示す青いラインがでる
ちゃんと動いていればね
コンソールにテストの内容と結果が表示される
グラハム メールは来た？
これで発表は終わりです
質問があればどうぞ 時間は大丈夫？
HudsonでSereniumは使えるか？ 使えるよ
PHPUnitからSereniumを実行しているかSereniumRCを使ってブラウザを動かしていれば
ちょっと設定は面倒だけど
PHPUnitからSereniumを実行して結果をチェックする
HudsonがPHPUnitを実行してPHPUnitがSereniumを実行して Sereniumがブラウザを実行し
PHPUnitがテストが失敗したかどうかを伝える
これで回答になったかな？ OK
何が動かないか？ 設定が面倒だけど
依存関係も多くないし
Hudsonはユニットテストフレームワークには関与しない
単にコンソールを見るのでSimpleTestでも問題ない
Hudsonのコンソールを見ればわかるけど
何が実行されてどうして失敗したのか
OK
後ろの人
まだ無理だね
じゃあありがとうございました