WEBVTT

00:00:06.947 --> 00:00:08.467
ユニットテストで人生に勝利する by Mark Story

00:00:08.467 --> 00:00:12.843
ユニットテストは開発の中で大事なプロセスです

00:00:12.843 --> 00:00:21.186
ユニットテストは手動でクリックするようなテストと違い

00:00:21.186 --> 00:00:24.107
自動化されたテストです

00:00:24.107 --> 00:00:27.402
今日は僕がどうしてユニットテストをしているか

00:00:27.402 --> 00:00:31.169
また実際のテストの方法についてお話しします

00:00:31.169 --> 00:00:34.899
テストしづらい部分をテストする方法や

00:00:34.899 --> 00:00:47.973
テストを最新の状態に保つ Continuous Integration についてもお話します

00:00:47.973 --> 00:00:52.009
大学を出てすぐにプログラミングを始めました

00:00:52.009 --> 00:00:54.719
お金が必要だったので（笑）

00:00:54.719 --> 00:01:01.123
CakePHPを使って2年半になります

00:01:01.123 --> 00:01:07.070
DebugKit や ApiGenerator などのプラグインを作りました

00:01:07.070 --> 00:01:10.465
普段は FreshBooks で働いています

00:01:10.465 --> 00:01:13.613
オンライン上で請求書を発行するようなサービスで

00:01:13.613 --> 00:01:16.673
そこではリードデベロッパをしています

00:01:16.673 --> 00:01:18.830
ユニットテストは僕を素晴らしくしてくれるのでしょうか？

00:01:18.830 --> 00:01:21.863
激しくその通りです

00:01:21.863 --> 00:01:24.273
何故ユニットテストをするのでしょうか

00:01:24.273 --> 00:01:37.430
余分な時間は掛かりますが、その他のコードが正しく動いているのを確認する為です

00:01:37.430 --> 00:01:42.532
特に後になってから起きた問題を修正する時間を削減するのが主な理由ですね

00:01:42.532 --> 00:01:47.073
何かを変更した後にそれまで動いていた部分が動いている事を確認する

00:01:47.073 --> 00:01:50.320
何かを変更して動いていた物を壊してしまった事はある人はどれくらい居ますか？

00:01:50.320 --> 00:01:53.617
(挙手多数)

00:01:53.617 --> 00:02:06.505
テストを書けばそういう事は起きません

00:02:06.505 --> 00:02:10.729
バグを見つけたらその部分のテストを書けば

00:02:10.729 --> 00:02:14.017
同じバグが発生する事はありません

00:02:14.017 --> 00:02:19.770
またユニットテストは複雑なコードの設計の助けにもなります

00:02:19.770 --> 00:02:23.552
プログラムをシンプルな部品に分割する

00:02:23.552 --> 00:02:33.004
例えば「CMSを作れ」という素晴らしいチケットがあった時

00:02:33.004 --> 00:02:36.765
細かいテストにブレークダウンして

00:02:36.765 --> 00:02:42.156
テストを一つづつパスさせれば、何かが動いた事になります

00:02:42.156 --> 00:02:45.776
またテストは生きたドキュメントにもなります

00:02:45.776 --> 00:02:52.110
内容を忘れてもテストを見ればわかります

00:02:52.110 --> 00:03:01.063
また問題を早めに見つける事もできます

00:03:01.063 --> 00:03:08.394
何か変なものをコードに入れてしまってもすぐにわかります

00:03:08.394 --> 00:03:14.336
コードの確実性を高める事もできます

00:03:14.336 --> 00:03:22.433
とにかく知っている範囲で動くようにテストを書きます

00:03:22.433 --> 00:03:33.734
クリックしながらテストをすると3時間かけても 自分の所では動いたと思うとしか言えません

00:03:33.734 --> 00:03:36.804
でも僕らには自動化された殺人兵器があります

00:03:36.804 --> 00:03:44.561
自動化されたテストの利点はまさに自動化されている事です

00:03:44.561 --> 00:03:49.168
CIもできますし、テストを素早く実行できます

00:03:49.168 --> 00:03:56.033
変更をする度に5時間かけてクリックするのではなく

00:03:56.033 --> 00:04:14.283
ボタンをクリックするだけで何か失敗していないかやきちんと動いているかが確認できますね

00:04:14.283 --> 00:04:17.697
テストできるものは全てテストするべきです

00:04:17.697 --> 00:04:20.458
夜中に問題を起こしそうなコード

00:04:20.458 --> 00:04:24.178
問題が起きる恐怖を軽減する為にテストを書きましょう

00:04:24.178 --> 00:04:36.872
また金銭に関わるようなコードにもテストを書けばユーザーやあなたが金銭を失わないようにできます

00:04:36.872 --> 00:04:47.175
また以前にも問題が起きた壊れやすいコードにもテストを書きましょう

00:04:47.175 --> 00:04:51.414
また手動でテストしにくいものにもテストを書きます

00:04:51.414 --> 00:05:06.492
PDFの生成のように時間がかかる部分にテストを書いた事があります

00:05:06.492 --> 00:05:09.217
またテストには異なる種類があります

00:05:09.217 --> 00:05:14.965
ユニットテストと機能テスト、結合テストです

00:05:14.965 --> 00:05:21.555
ユニットテストはアプリケーションの細かい部分のテスト

00:05:21.555 --> 00:05:36.460
オブジェクトやメソッド、関数単位で正しい結果を返しているかなどをテストします

00:05:36.460 --> 00:05:44.232
また多くの場合モックを使います　これはテストしづらい部分をテストするのにとても便利です

00:05:44.232 --> 00:05:51.291
テスト駆動開発をする際にもユニットテストは便利です

00:05:51.291 --> 00:05:56.669
テスト駆動開発ではコードを書く前にテストを書きます

00:05:56.669 --> 00:06:07.951
テストを書いて コードを書いて またテストを書いてコードを書く　その繰り返しですね

00:06:07.951 --> 00:06:12.877
テストが失敗するようなコードを本番環境向けに書かない

00:06:12.877 --> 00:06:16.642
僕は普段、コードを書いてそれからテストを書きます

00:06:16.642 --> 00:06:22.053
そしてテストが壊れないように余分なコードを消します

00:06:22.053 --> 00:06:35.570
機能テストは部品が一緒にうまく動作するかをテストします

00:06:35.570 --> 00:06:41.195
上位のオブジェクトから部品が正しく動いているかをテストする

00:06:41.195 --> 00:06:53.747
例えばCakePHPもModelが変更されたら結合テストを行う

00:06:53.747 --> 00:06:55.652
あなたが書いたコードだけなく　データベースと通信する部分などが正しく動いている事をテストする

00:06:55.652 --> 00:06:58.964
機能テストは比較的時間がかかります

00:06:58.964 --> 00:07:03.234
多くのリソースやデータベースを使うからです

00:07:03.234 --> 00:07:07.131
さらにはリモートのサービスを実行したりもします

00:07:07.131 --> 00:07:11.372
ユニットテストは基本的に1つのクラスのテストです

00:07:11.372 --> 00:07:14.222
細かい部品ごとに正しい動作をテストする

00:07:14.222 --> 00:07:18.475
それをまとめてに行うのが結合テストです

00:07:18.475 --> 00:07:21.974
テストをする時にはいくつかの課題があります

00:07:21.974 --> 00:07:24.779
ちょっと水を飲みます

00:07:24.779 --> 00:07:28.636
話すのが速すぎるかな？　大丈夫？

00:07:28.636 --> 00:07:33.161
まずはテストを書くのに時間がかかる事

00:07:33.161 --> 00:07:46.646
しかし同じバグを何度も修正するのはもっと時間がかかります

00:07:46.646 --> 00:07:48.821
正しいテストを書けば同じバグはもう起こりません

00:07:48.821 --> 00:07:52.187
テストは問題がある事しか証明しません

00:07:52.187 --> 00:07:55.853
問題が無い事は証明しません

00:07:55.853 --> 00:07:58.466
1つテストがあるのはバグが無いという意味ではなく、1つのバグがテストされたという事にしかなりません

00:07:58.466 --> 00:08:06.591
またユニットテストはテストがある部分のエラーしか見つけられません

00:08:06.591 --> 00:08:15.969
コンピューターはテストがある部分だけテストします

00:08:15.969 --> 00:08:24.350
なのでありえるパラメータ範囲などもテストを書かないといけません

00:08:24.350 --> 00:08:28.474
テストの利点はなんでしょうか

00:08:28.474 --> 00:08:32.871
余分な手間が最初にかかりますが、問題を早く見つける事ができます

00:08:32.871 --> 00:08:42.384
QAテスターや上司がクリックして「どうして壊れてるんだ」と聞かれる前に問題を見つけられます

00:08:42.384 --> 00:08:45.234
またテストのプロセスを自動化する事が出来ます

00:08:45.234 --> 00:08:57.288
自動化はすばらしいです　フレームワークも色々な事を自動化してくれますが　テストはもっと自動化してくれます

00:08:57.288 --> 00:09:02.242
またユニットテストは結合テストに発展させる事もできます

00:09:02.242 --> 00:09:09.913
セレニウムのスクリプトを書いてコンソールから

00:09:09.913 --> 00:09:14.289
ブラウザでクリックするようなテストを実行できます

00:09:14.289 --> 00:09:17.533
これはほんとに素晴らしいです

00:09:17.533 --> 00:09:22.848
決められた仕様をテストにすれば

00:09:22.848 --> 00:09:31.774
テストがパスすれば仕様を満たせている事が確認できます

00:09:31.774 --> 00:09:38.958
以上でテストの素晴らしさの賞賛は終わりです

00:09:38.958 --> 00:09:44.094
次にモックオブジェクトの話題

00:09:44.094 --> 00:09:53.391
モックオブジェクトはテストしづらい部分をテストする際にとても便利です

00:09:53.391 --> 00:10:06.340
個別のテストを書きづらい時にモックオブジェクトを使えば簡単になります

00:10:06.340 --> 00:10:11.472
オブジェクト同士を呼び合わないようにテストさせる事ができます

00:10:11.472 --> 00:10:16.752
オブジェクトがそれぞれ間違った方法で呼び出し合って

00:10:16.752 --> 00:10:23.095
テストが失敗するのを防げます

00:10:23.095 --> 00:10:27.022
またモックは実装前にオブジェクトの振る舞いを確認する助けにもなります

00:10:27.022 --> 00:10:37.004
例えば何かのサービスにPOSTして結果を配列で返すようなクラスの場合

00:10:37.004 --> 00:10:42.455
例えばそのサービスが友達のジョーが書くとしたそれがどうなるのか予測できません

00:10:42.455 --> 00:10:52.116
必要な配列を返すモックがあればジョーの方で問題があっても関係ない

00:10:52.116 --> 00:10:59.392
ジョーの部分が終ったらジョーがその部分に対してテストを書けばよい

00:10:59.392 --> 00:11:03.680
そうすれば僕はジョーの所で何をやっているかは知らなくても大丈夫

00:11:03.680 --> 00:11:10.112
モックをグローバル関数やグローバルなスコープで読み込まれるファイルに使えるでしょうか？

00:11:10.112 --> 00:11:13.745
使えません

00:11:13.745 --> 00:11:22.365
モックを使うにはクラスになっていて、処理がメソッドの中にある必要があります

00:11:22.365 --> 00:11:26.067
モックはどういう時に使うべきでしょうか？

00:11:26.067 --> 00:11:29.194
モックは外部と通信するようなコストが高かったり　危険の大きい時に使うのがベストです

00:11:29.194 --> 00:11:39.760
テストを実行する度に顧客にEメールを送信なんて事ありえないよね（笑）

00:11:39.760 --> 00:11:48.960
メール送信処理はサーバーとの通信などのコストも高い

00:11:48.960 --> 00:11:53.011
そういった外部依存を少なくする

00:11:53.011 --> 00:11:59.018
TwitterやPaypalなどと通信する部分にモックを使うのもパーフェクトな例

00:11:59.018 --> 00:12:13.861
Twitterが落ちてしまうとコードが壊れていないのにテストが失敗してしまう

00:12:13.861 --> 00:12:20.125
この部分にモックを使っておけばTwitterが落ちても開発を継続できる

00:12:20.125 --> 00:12:26.020
また落ちた事が無いようなサービスにモックを使っておけば

00:12:26.020 --> 00:12:35.220
そのサービスが落ちてしまった時に自分のコードに何が起きるのかを知る事ができる

00:12:35.220 --> 00:12:45.604
例えばPaypalが落ちた時にコードが爆発してしまうのか　そのまま動いてしまうかは知っておくべきだ

00:12:45.604 --> 00:12:49.467
ユニットテストとモックを使えばこういった事態を想定できる

00:12:49.467 --> 00:12:57.787
またユニットテスト中で不必要に大量にディスクに書き込みをしてしまう場合もモックにできる

00:12:57.787 --> 00:13:01.565
データベースもご存知の通り遅いのでモックにできる

00:13:01.565 --> 00:13:04.621
データベースに /dev/null でも使ってない限りはね (笑)

00:13:04.621 --> 00:13:12.347
/dev/null はWEBスケーラブルだ (有名なジョーク)

00:13:12.347 --> 00:13:19.779
データベースへの書き込みは遅くてコストかかるのでモックを使えばたくさんのテストを実行するのに便利だ

00:13:19.779 --> 00:13:25.389
本当にデータベースに通信しなければいけない場合は別だけど　大抵の場合はそうじゃないね

00:13:25.389 --> 00:13:38.601
クラスが２つある場合　それぞれが正しく呼び出し合っている事を確認することになる

00:13:38.601 --> 00:13:49.724
その場合にスタブとしてモックを使う事ができる　それぞれが期待する動作をモックに実装する

00:13:49.724 --> 00:13:53.784
期待しないパラメータが呼び出されたらテストが失敗するようにしておく

00:13:53.784 --> 00:13:57.336
そうやって問題の範囲を絞って

00:13:57.336 --> 00:14:08.539
個別のコードが動くために必要な部分をスタブ化して扱いやすくする

00:14:08.539 --> 00:14:20.415
そうすれば問題を分離できる

00:14:20.415 --> 00:14:24.106
例えばこのメソッドがNullを返すとエラーが起きる時に

00:14:24.106 --> 00:14:27.836
ファイルがおかしい時にNullになるなんて時にモックを使ってテストすれば問題を分離できる

00:14:27.836 --> 00:14:33.019
どうやってモックを作るか

00:14:33.019 --> 00:14:40.175
モックにするには依存関係を実行時に変更できる必要がある

00:14:40.175 --> 00:14:48.140
僕が使っている3つの方法はコンストラクタ渡しとファクトリーメソッドとセッターメソッドだね

00:14:48.140 --> 00:14:50.532
それぞれの例ではPHPUnitのモックを使っているけど質問があれば聞いてください

00:14:50.532 --> 00:15:06.745
コンストラクタ渡しはJavaなんかで古くから使われている依存関係の処理で

00:15:06.745 --> 00:15:12.139
依存するクラスのオブジェクトをコンストラクタで受け取るようにする方法だ

00:15:12.139 --> 00:15:21.091
このCarクラスの場合はエンジンとドライバーのオブジェクトをコンストラクタで受け取っている

00:15:21.091 --> 00:15:28.277
モックを使いたい時はエンジンやドライバーのモックオブジェクトを変わりに渡せばいい

00:15:28.277 --> 00:15:31.941
次はファクトリーメソッド

00:15:31.941 --> 00:15:36.671
ファクトリーメソッドはサブクラスでモックを返すようにオーバーライドすればいい

00:15:36.671 --> 00:15:40.390
このRaceCarクラスはエンジンのオブジェクトをgetEngineメソッドから取得する

00:15:40.390 --> 00:15:51.297
モックを使う場合はgetEngineメソッドを別のオブジェクトを返すようにオーバーライドすればいい

00:15:51.297 --> 00:16:02.238
さらに別の方法がセッターメソッド

00:16:02.238 --> 00:16:09.677
フレームワークやツールでよくあるようにsetやgetでオブジェクトを操作する方法だ

00:16:09.677 --> 00:16:14.857
これなら簡単にオブジェクトを入れ替える事ができる

00:16:14.857 --> 00:16:20.770
GiantEngineを入れ替えたければsetEngineを使える

00:16:20.770 --> 00:16:26.618
モックはテストの目的によっては重要になる

00:16:26.618 --> 00:16:31.252
モックやスタブで危険なオブジェクトやメソッドをテストから除く事ができる

00:16:31.252 --> 00:16:39.811
モックを使ってオブジェクトが他のオブジェクトを正しく扱っているかを確かめられる

00:16:39.811 --> 00:16:45.802
この例ではgetMockメソッドでモックを取得し

00:16:45.802 --> 00:16:50.172
何かしら危険なtypeメソッドをスタブ化している

00:16:50.172 --> 00:17:12.006
最初はjsonのパラメータが渡され　次の例ではxmlのパラメータが渡されている事をチェックしている

00:17:12.006 --> 00:17:31.896
RequestHandlerオブジェクトが正しく動いていればテストはパスするはず

00:17:31.896 --> 00:17:46.246
テストの中でオブジェクトを作る時にモックを作り　期待するパラメータごとの結果をスタブ化する

00:17:46.246 --> 00:18:09.820
これはCake2の実際のテストの例だけど

00:18:09.820 --> 00:18:15.959
危険な処理のスタブ化

00:18:15.959 --> 00:18:19.196
ヘッダーの送信の処理は危険な処理だ

00:18:19.196 --> 00:18:26.652
外部のサービスに通信する処理もそうだし

00:18:26.652 --> 00:18:35.524
呼び出しの度に課金が発生するようなサービスをテストの度に呼び出すのはよくないやりかただ

00:18:35.524 --> 00:18:39.664
そういった場合にスタブを使えばいい

00:18:39.664 --> 00:18:54.364
さっきのやり方と同じでヘッダを送るメソッドをスタブ化している

00:18:54.364 --> 00:19:00.759
statusCodeメソッドが呼び出された場合は301

00:19:00.759 --> 00:19:12.725
headerが呼び出された場合はLocationとURLの２つのパラメーターが渡る事を期待している

00:19:12.725 --> 00:19:32.701
どうしてスタブ化するかというと　オブジェクトがheader関数を呼んでしまうからだ

00:19:32.701 --> 00:19:38.323
スタブ化しないで実行してしまうとテストの度にcakephpのサイトを見る事になってしまう

00:19:38.323 --> 00:19:46.901
モックを使ってテスト時に起こる良くない現象を解決している

00:19:46.901 --> 00:19:51.213
コストのかかる処理のスタブ化

00:19:51.213 --> 00:19:56.300
このCampainMontiorは遅いので隠してしまおう

00:19:56.300 --> 00:20:11.120
幾つか連絡先の情報を作っておいてモックを作り

00:20:11.120 --> 00:20:23.133
このメソッドが呼ばれた時はこのデータが返ってくるとみなす

00:20:23.133 --> 00:20:33.615
DependencyInjectionでこのクラス全体を置き換える事もできるけど

00:20:33.615 --> 00:20:43.613
モックを使って自動的にメソッドが呼ばれた時の戻り値を設定してる

00:20:43.613 --> 00:20:48.582
わかるかな？

00:20:48.582 --> 00:21:01.749
この場合だとonceなので2回呼び出された場合はテストが失敗する

00:21:01.749 --> 00:21:14.451
厳密に数値ごとの結果を定義してテストを失敗させることもできる

00:21:14.451 --> 00:21:17.706
このセクションのまとめ

00:21:17.706 --> 00:21:31.802
モックはテストを素早く実行させたり、テストの事前事後の処理を少なくする事ができる

00:21:31.802 --> 00:21:40.986
外部サービスを呼ぶような場合もスタブ化してしまえば

00:21:40.986 --> 00:21:45.060
本当の意味でのユニットテストが実行できる

00:21:45.060 --> 00:21:52.572
重要なところをテストして余分なものを分離する

00:21:52.572 --> 00:22:04.544
以上でモックの話はおわり

00:22:04.544 --> 00:22:09.282
もちろんSimpleTestにもモックオブジェクトはある

00:22:09.282 --> 00:22:14.495
コアクラスのテストケースを見れば大量にモックを使っているのがわかると思う

00:22:14.495 --> 00:22:19.130
自動殺人ロボット

00:22:19.130 --> 00:22:23.500
人体模型でも出来る自動テストだ

00:22:23.500 --> 00:22:38.003
実行されていないテストは消していい

00:22:38.003 --> 00:22:42.758
こういう場合ビルドサーバーを建てよう

00:22:42.758 --> 00:22:47.881
Hudsonはとても使いやすいJava製のビルドサーバーだ

00:22:47.881 --> 00:22:57.432
たくさんのプラグインがあってメールを送ったり、Jabberにメッセージを送ったりできる

00:22:57.432 --> 00:23:03.784
テストがコードをどれだけカバーしているかのカバレッジレポートを出すこともできる

00:23:03.784 --> 00:23:17.529
テストを毎晩とか毎時とか毎日にスケジュールしたり、ポストコミットのフックを設定もできる

00:23:17.529 --> 00:23:21.438
起動したHudsonはコードをチェックアウトして

00:23:21.438 --> 00:23:26.795
さらにスクリプトを実行してテストを行う

00:23:26.795 --> 00:23:30.523
SvnでもGitでも使える

00:23:30.523 --> 00:23:35.424
MercurrealやBazarも大丈夫　使わない理由はないね

00:23:35.424 --> 00:23:43.826
一般的なのはコミットやプッシュの度にテストを実行する

00:23:43.826 --> 00:23:52.688
短い間隔でジョブを待機させてテストする

00:23:52.688 --> 00:24:08.614
開発が進んでない場合も夜間にテストを実行する

00:24:08.614 --> 00:24:19.222
サーバーが空いている時にカバレッジレポートを出力する

00:24:19.222 --> 00:24:24.503
Hudsonのセットアップは今見せようと思ったけどネットワークがおかしいみたいで

00:24:24.503 --> 00:24:28.608
夕べやったやつをお見せします

00:24:28.608 --> 00:24:39.706
wgetでダウンロードしてjavaコマンドで実行する

00:24:39.706 --> 00:24:47.330
ターミナルの大きさお変えて

00:24:47.330 --> 00:24:50.688
Hudsonのディレクトリを開く

00:24:50.688 --> 00:25:08.481
見えるかな？

00:25:08.481 --> 00:25:14.364
Hudsonは他のJavaプログラムと違ってコンテナやTomcat無しで

00:25:14.364 --> 00:25:19.731
5000の依存関係をコンパイルしたりしなくても

00:25:19.731 --> 00:25:24.233
1ファイルをダウンロードして実行できる

00:25:24.233 --> 00:25:28.263
インストールに何時間もかかってTomcatを入れてなんて

00:25:28.263 --> 00:25:38.447
事も前にあったけど

00:25:38.447 --> 00:25:44.257
これでローカルでHudsonが動いている

00:25:44.257 --> 00:25:49.089
localhostの8080にアクセスして

00:25:49.089 --> 00:26:01.992
おっと

00:26:01.992 --> 00:26:09.539
(.comを指摘されて)みなさんのほうが賢いみたいだ

00:26:09.539 --> 00:26:14.835
これが僕のマシンの上のHudson

00:26:14.835 --> 00:26:28.648
この画面でHudsonの管理ができる

00:26:28.648 --> 00:26:33.549
ビルドの履歴をプロジェクトリストから見たり

00:26:33.549 --> 00:26:43.839
最後にテストが失敗したか成功したかが見れる

00:26:43.839 --> 00:26:53.145
これはプロジェクトの例

00:26:53.145 --> 00:27:03.555
テストのプロジェクトを作ってみよう

00:27:03.555 --> 00:27:16.255
フリースタイルプロジェクトを選んで

00:27:16.255 --> 00:27:34.451
gitリポジトリを使う

00:27:34.451 --> 00:27:48.588
このブランチを使って

00:27:48.588 --> 00:27:53.887
手動でビルドしたり定期的にビルドしたり　SCMから呼ばれたりもできる

00:27:53.887 --> 00:27:57.054
実行するシェルの設定

00:27:57.054 --> 00:28:05.300
cakeのコンソールを使ってテストを実行

00:28:05.300 --> 00:28:18.304
コアのヘルパーのテストを実行するようにする

00:28:18.304 --> 00:28:25.777
メールの送信を設定

00:28:25.777 --> 00:28:29.968
誰かメールを受け取りたいかい？

00:28:29.968 --> 00:28:53.110
誰もいない？　じゃあグラハムだ

00:28:53.110 --> 00:29:01.966
ビルドが失敗する度に君にメールを送る

00:29:01.966 --> 00:29:05.553
ビルドを壊した人にメールを送るなんてのもあるね

00:29:05.553 --> 00:29:14.095
これでプロジェクトは設定できた

00:29:14.095 --> 00:29:19.126
これでビルドが失敗するとすぐに「マークがビルドを失敗させた」と周知する事ができる

00:29:19.126 --> 00:29:32.172
これで壊した人が責任をもって直すようになるね

00:29:32.172 --> 00:29:44.449
実にすばらしい

00:29:44.449 --> 00:29:47.287
ビルド中だね

00:29:47.287 --> 00:29:49.971
♪

00:29:49.971 --> 00:29:53.280
Hudsonには複数のプロジェクトを作成できる

00:29:53.280 --> 00:30:00.070
Hudsonはリポジトリからローカルにコードを持ってきて

00:30:00.070 --> 00:30:04.306
指定されたコマンドを実行する

00:30:04.306 --> 00:30:09.810
cakeコマンドとか必要なら他のコマンドも先に実行できる

00:30:09.810 --> 00:30:18.251
そして最後のコマンドのexitステータスが失敗ならビルドは失敗した事になる

00:30:18.251 --> 00:30:23.684
exitステータスが成功ならビルドも成功

00:30:23.684 --> 00:30:30.462
コンソールのアウトプットを見てみよう

00:30:30.462 --> 00:30:34.543
githubからクローン中だね

00:30:34.543 --> 00:30:38.473
時間がかかりそうだ

00:30:38.473 --> 00:30:54.266
(ネットワークが不調)失敗しそうだ

00:30:54.266 --> 00:30:58.248
ビルド失敗だね

00:30:58.248 --> 00:31:04.622
1分前に失敗　グラハムにはメールが届くはずだ

00:31:04.622 --> 00:31:12.032
設定を変更

00:31:12.032 --> 00:31:20.011
(ローカルのリポジトリに変更)

00:31:20.011 --> 00:31:32.683
これで動くかな

00:31:32.683 --> 00:31:42.132
ディレクトリ名で動くらしい　グラハムによると

00:31:42.132 --> 00:31:51.754
実行中だ

00:31:51.754 --> 00:32:04.231
ネット接続が面白い事になってるね

00:32:04.231 --> 00:32:15.614
失敗だ

00:32:15.614 --> 00:32:26.124
ネットワーク接続があればなー

00:32:26.124 --> 00:32:34.568
遅いな

00:32:34.568 --> 00:32:47.223
やっぱり繋がってないな

00:32:47.223 --> 00:32:53.413
本来ならここにビルド成功を示す青いラインがでる

00:32:53.413 --> 00:33:00.604
ちゃんと動いていればね

00:33:00.604 --> 00:33:25.191
コンソールにテストの内容と結果が表示される

00:33:25.191 --> 00:33:31.027
グラハム　メールは来た？

00:33:31.027 --> 00:33:40.241
これで発表は終わりです

00:33:40.241 --> 00:33:50.208
質問があればどうぞ　時間は大丈夫？

00:33:50.208 --> 00:34:01.778
HudsonでSereniumは使えるか？　使えるよ

00:34:01.778 --> 00:34:11.606
PHPUnitからSereniumを実行しているかSereniumRCを使ってブラウザを動かしていれば

00:34:11.606 --> 00:34:15.919
ちょっと設定は面倒だけど

00:34:15.919 --> 00:34:24.996
PHPUnitからSereniumを実行して結果をチェックする

00:34:24.996 --> 00:34:31.380
HudsonがPHPUnitを実行してPHPUnitがSereniumを実行して Sereniumがブラウザを実行し

00:34:31.380 --> 00:34:35.996
PHPUnitがテストが失敗したかどうかを伝える

00:34:35.996 --> 00:34:40.197
これで回答になったかな？　OK

00:34:40.197 --> 00:34:48.514
何が動かないか？　設定が面倒だけど

00:34:48.514 --> 00:34:58.546
依存関係も多くないし

00:34:58.546 --> 00:35:22.092
Hudsonはユニットテストフレームワークには関与しない

00:35:22.092 --> 00:35:30.416
単にコンソールを見るのでSimpleTestでも問題ない

00:35:30.416 --> 00:35:34.339
Hudsonのコンソールを見ればわかるけど

00:35:34.339 --> 00:35:42.063
何が実行されてどうして失敗したのか

00:35:42.063 --> 00:35:44.676
OK

00:35:44.676 --> 00:35:49.523
後ろの人

00:35:49.523 --> 00:36:13.812
まだ無理だね

00:36:13.812 --> 00:36:18.625
じゃあありがとうございました