1
00:00:06,947 --> 00:00:08,467
ユニットテストで人生に勝利する by Mark Story

2
00:00:08,467 --> 00:00:12,843
ユニットテストは開発の中で大事なプロセスです

3
00:00:12,843 --> 00:00:21,186
ユニットテストは手動でクリックするようなテストと違い

4
00:00:21,186 --> 00:00:24,107
自動化されたテストです

5
00:00:24,107 --> 00:00:27,402
今日は僕がどうしてユニットテストをしているか

6
00:00:27,402 --> 00:00:31,169
また実際のテストの方法についてお話しします

7
00:00:31,169 --> 00:00:34,899
テストしづらい部分をテストする方法や

8
00:00:34,899 --> 00:00:47,973
テストを最新の状態に保つ Continuous Integration についてもお話します

9
00:00:47,973 --> 00:00:52,009
大学を出てすぐにプログラミングを始めました

10
00:00:52,009 --> 00:00:54,719
お金が必要だったので（笑）

11
00:00:54,719 --> 00:01:01,123
CakePHPを使って2年半になります

12
00:01:01,123 --> 00:01:07,070
DebugKit や ApiGenerator などのプラグインを作りました

13
00:01:07,070 --> 00:01:10,465
普段は FreshBooks で働いています

14
00:01:10,465 --> 00:01:13,613
オンライン上で請求書を発行するようなサービスで

15
00:01:13,613 --> 00:01:16,673
そこではリードデベロッパをしています

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

17
00:01:18,830 --> 00:01:21,863
激しくその通りです

18
00:01:21,863 --> 00:01:24,273
何故ユニットテストをするのでしょうか

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

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

21
00:01:42,532 --> 00:01:47,073
何かを変更した後にそれまで動いていた部分が動いている事を確認する

22
00:01:47,073 --> 00:01:50,320
何かを変更して動いていた物を壊してしまった事はある人はどれくらい居ますか？

23
00:01:50,320 --> 00:01:53,617
(挙手多数)

24
00:01:53,617 --> 00:02:06,505
テストを書けばそういう事は起きません

25
00:02:06,505 --> 00:02:10,729
バグを見つけたらその部分のテストを書けば

26
00:02:10,729 --> 00:02:14,017
同じバグが発生する事はありません

27
00:02:14,017 --> 00:02:19,770
またユニットテストは複雑なコードの設計の助けにもなります

28
00:02:19,770 --> 00:02:23,552
プログラムをシンプルな部品に分割する

29
00:02:23,552 --> 00:02:33,004
例えば「CMSを作れ」という素晴らしいチケットがあった時

30
00:02:33,004 --> 00:02:36,765
細かいテストにブレークダウンして

31
00:02:36,765 --> 00:02:42,156
テストを一つづつパスさせれば、何かが動いた事になります

32
00:02:42,156 --> 00:02:45,776
またテストは生きたドキュメントにもなります

33
00:02:45,776 --> 00:02:52,110
内容を忘れてもテストを見ればわかります

34
00:02:52,110 --> 00:03:01,063
また問題を早めに見つける事もできます

35
00:03:01,063 --> 00:03:08,394
何か変なものをコードに入れてしまってもすぐにわかります

36
00:03:08,394 --> 00:03:14,336
コードの確実性を高める事もできます

37
00:03:14,336 --> 00:03:22,433
とにかく知っている範囲で動くようにテストを書きます

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

39
00:03:33,734 --> 00:03:36,804
でも僕らには自動化された殺人兵器があります

40
00:03:36,804 --> 00:03:44,561
自動化されたテストの利点はまさに自動化されている事です

41
00:03:44,561 --> 00:03:49,168
CIもできますし、テストを素早く実行できます

42
00:03:49,168 --> 00:03:56,033
変更をする度に5時間かけてクリックするのではなく

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

44
00:04:14,283 --> 00:04:17,697
テストできるものは全てテストするべきです

45
00:04:17,697 --> 00:04:20,458
夜中に問題を起こしそうなコード

46
00:04:20,458 --> 00:04:24,178
問題が起きる恐怖を軽減する為にテストを書きましょう

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

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

49
00:04:47,175 --> 00:04:51,414
また手動でテストしにくいものにもテストを書きます

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

51
00:05:06,492 --> 00:05:09,217
またテストには異なる種類があります

52
00:05:09,217 --> 00:05:14,965
ユニットテストと機能テスト、結合テストです

53
00:05:14,965 --> 00:05:21,555
ユニットテストはアプリケーションの細かい部分のテスト

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

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

56
00:05:44,232 --> 00:05:51,291
テスト駆動開発をする際にもユニットテストは便利です

57
00:05:51,291 --> 00:05:56,669
テスト駆動開発ではコードを書く前にテストを書きます

58
00:05:56,669 --> 00:06:07,951
テストを書いて コードを書いて またテストを書いてコードを書く　その繰り返しですね

59
00:06:07,951 --> 00:06:12,877
テストが失敗するようなコードを本番環境向けに書かない

60
00:06:12,877 --> 00:06:16,642
僕は普段、コードを書いてそれからテストを書きます

61
00:06:16,642 --> 00:06:22,053
そしてテストが壊れないように余分なコードを消します

62
00:06:22,053 --> 00:06:35,570
機能テストは部品が一緒にうまく動作するかをテストします

63
00:06:35,570 --> 00:06:41,195
上位のオブジェクトから部品が正しく動いているかをテストする

64
00:06:41,195 --> 00:06:53,747
例えばCakePHPもModelが変更されたら結合テストを行う

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

66
00:06:55,652 --> 00:06:58,964
機能テストは比較的時間がかかります

67
00:06:58,964 --> 00:07:03,234
多くのリソースやデータベースを使うからです

68
00:07:03,234 --> 00:07:07,131
さらにはリモートのサービスを実行したりもします

69
00:07:07,131 --> 00:07:11,372
ユニットテストは基本的に1つのクラスのテストです

70
00:07:11,372 --> 00:07:14,222
細かい部品ごとに正しい動作をテストする

71
00:07:14,222 --> 00:07:18,475
それをまとめてに行うのが結合テストです

72
00:07:18,475 --> 00:07:21,974
テストをする時にはいくつかの課題があります

73
00:07:21,974 --> 00:07:24,779
ちょっと水を飲みます

74
00:07:24,779 --> 00:07:28,636
話すのが速すぎるかな？　大丈夫？

75
00:07:28,636 --> 00:07:33,161
まずはテストを書くのに時間がかかる事

76
00:07:33,161 --> 00:07:46,646
しかし同じバグを何度も修正するのはもっと時間がかかります

77
00:07:46,646 --> 00:07:48,821
正しいテストを書けば同じバグはもう起こりません

78
00:07:48,821 --> 00:07:52,187
テストは問題がある事しか証明しません

79
00:07:52,187 --> 00:07:55,853
問題が無い事は証明しません

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

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

82
00:08:06,591 --> 00:08:15,969
コンピューターはテストがある部分だけテストします

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

84
00:08:24,350 --> 00:08:28,474
テストの利点はなんでしょうか

85
00:08:28,474 --> 00:08:32,871
余分な手間が最初にかかりますが、問題を早く見つける事ができます

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

87
00:08:42,384 --> 00:08:45,234
またテストのプロセスを自動化する事が出来ます

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

89
00:08:57,288 --> 00:09:02,242
またユニットテストは結合テストに発展させる事もできます

90
00:09:02,242 --> 00:09:09,913
セレニウムのスクリプトを書いてコンソールから

91
00:09:09,913 --> 00:09:14,289
ブラウザでクリックするようなテストを実行できます

92
00:09:14,289 --> 00:09:17,533
これはほんとに素晴らしいです

93
00:09:17,533 --> 00:09:22,848
決められた仕様をテストにすれば

94
00:09:22,848 --> 00:09:31,774
テストがパスすれば仕様を満たせている事が確認できます

95
00:09:31,774 --> 00:09:38,958
以上でテストの素晴らしさの賞賛は終わりです

96
00:09:38,958 --> 00:09:44,094
次にモックオブジェクトの話題

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

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

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

100
00:10:11,472 --> 00:10:16,752
オブジェクトがそれぞれ間違った方法で呼び出し合って

101
00:10:16,752 --> 00:10:23,095
テストが失敗するのを防げます

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

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

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

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

106
00:10:52,116 --> 00:10:59,392
ジョーの部分が終ったらジョーがその部分に対してテストを書けばよい

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

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

109
00:11:10,112 --> 00:11:13,745
使えません

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

111
00:11:22,365 --> 00:11:26,067
モックはどういう時に使うべきでしょうか？

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

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

114
00:11:39,760 --> 00:11:48,960
メール送信処理はサーバーとの通信などのコストも高い

115
00:11:48,960 --> 00:11:53,011
そういった外部依存を少なくする

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

117
00:11:59,018 --> 00:12:13,861
Twitterが落ちてしまうとコードが壊れていないのにテストが失敗してしまう

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

119
00:12:20,125 --> 00:12:26,020
また落ちた事が無いようなサービスにモックを使っておけば

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

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

122
00:12:45,604 --> 00:12:49,467
ユニットテストとモックを使えばこういった事態を想定できる

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

124
00:12:57,787 --> 00:13:01,565
データベースもご存知の通り遅いのでモックにできる

125
00:13:01,565 --> 00:13:04,621
データベースに /dev/null でも使ってない限りはね (笑)

126
00:13:04,621 --> 00:13:12,347
/dev/null はWEBスケーラブルだ (有名なジョーク)

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

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

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

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

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

132
00:13:53,784 --> 00:13:57,336
そうやって問題の範囲を絞って

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

134
00:14:08,539 --> 00:14:20,415
そうすれば問題を分離できる

135
00:14:20,415 --> 00:14:24,106
例えばこのメソッドがNullを返すとエラーが起きる時に

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

137
00:14:27,836 --> 00:14:33,019
どうやってモックを作るか

138
00:14:33,019 --> 00:14:40,175
モックにするには依存関係を実行時に変更できる必要がある

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

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

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

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

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

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

145
00:15:28,277 --> 00:15:31,941
次はファクトリーメソッド

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

147
00:15:36,671 --> 00:15:40,390
このRaceCarクラスはエンジンのオブジェクトをgetEngineメソッドから取得する

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

149
00:15:51,297 --> 00:16:02,238
さらに別の方法がセッターメソッド

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

151
00:16:09,677 --> 00:16:14,857
これなら簡単にオブジェクトを入れ替える事ができる

152
00:16:14,857 --> 00:16:20,770
GiantEngineを入れ替えたければsetEngineを使える

153
00:16:20,770 --> 00:16:26,618
モックはテストの目的によっては重要になる

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

155
00:16:31,252 --> 00:16:39,811
モックを使ってオブジェクトが他のオブジェクトを正しく扱っているかを確かめられる

156
00:16:39,811 --> 00:16:45,802
この例ではgetMockメソッドでモックを取得し

157
00:16:45,802 --> 00:16:50,172
何かしら危険なtypeメソッドをスタブ化している

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

159
00:17:12,006 --> 00:17:31,896
RequestHandlerオブジェクトが正しく動いていればテストはパスするはず

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

161
00:17:46,246 --> 00:18:09,820
これはCake2の実際のテストの例だけど

162
00:18:09,820 --> 00:18:15,959
危険な処理のスタブ化

163
00:18:15,959 --> 00:18:19,196
ヘッダーの送信の処理は危険な処理だ

164
00:18:19,196 --> 00:18:26,652
外部のサービスに通信する処理もそうだし

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

166
00:18:35,524 --> 00:18:39,664
そういった場合にスタブを使えばいい

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

168
00:18:54,364 --> 00:19:00,759
statusCodeメソッドが呼び出された場合は301

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

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

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

172
00:19:38,323 --> 00:19:46,901
モックを使ってテスト時に起こる良くない現象を解決している

173
00:19:46,901 --> 00:19:51,213
コストのかかる処理のスタブ化

174
00:19:51,213 --> 00:19:56,300
このCampainMontiorは遅いので隠してしまおう

175
00:19:56,300 --> 00:20:11,120
幾つか連絡先の情報を作っておいてモックを作り

176
00:20:11,120 --> 00:20:23,133
このメソッドが呼ばれた時はこのデータが返ってくるとみなす

177
00:20:23,133 --> 00:20:33,615
DependencyInjectionでこのクラス全体を置き換える事もできるけど

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

179
00:20:43,613 --> 00:20:48,582
わかるかな？

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

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

182
00:21:14,451 --> 00:21:17,706
このセクションのまとめ

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

184
00:21:31,802 --> 00:21:40,986
外部サービスを呼ぶような場合もスタブ化してしまえば

185
00:21:40,986 --> 00:21:45,060
本当の意味でのユニットテストが実行できる

186
00:21:45,060 --> 00:21:52,572
重要なところをテストして余分なものを分離する

187
00:21:52,572 --> 00:22:04,544
以上でモックの話はおわり

188
00:22:04,544 --> 00:22:09,282
もちろんSimpleTestにもモックオブジェクトはある

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

190
00:22:14,495 --> 00:22:19,130
自動殺人ロボット

191
00:22:19,130 --> 00:22:23,500
人体模型でも出来る自動テストだ

192
00:22:23,500 --> 00:22:38,003
実行されていないテストは消していい

193
00:22:38,003 --> 00:22:42,758
こういう場合ビルドサーバーを建てよう

194
00:22:42,758 --> 00:22:47,881
Hudsonはとても使いやすいJava製のビルドサーバーだ

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

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

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

198
00:23:17,529 --> 00:23:21,438
起動したHudsonはコードをチェックアウトして

199
00:23:21,438 --> 00:23:26,795
さらにスクリプトを実行してテストを行う

200
00:23:26,795 --> 00:23:30,523
SvnでもGitでも使える

201
00:23:30,523 --> 00:23:35,424
MercurrealやBazarも大丈夫　使わない理由はないね

202
00:23:35,424 --> 00:23:43,826
一般的なのはコミットやプッシュの度にテストを実行する

203
00:23:43,826 --> 00:23:52,688
短い間隔でジョブを待機させてテストする

204
00:23:52,688 --> 00:24:08,614
開発が進んでない場合も夜間にテストを実行する

205
00:24:08,614 --> 00:24:19,222
サーバーが空いている時にカバレッジレポートを出力する

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

207
00:24:24,503 --> 00:24:28,608
夕べやったやつをお見せします

208
00:24:28,608 --> 00:24:39,706
wgetでダウンロードしてjavaコマンドで実行する

209
00:24:39,706 --> 00:24:47,330
ターミナルの大きさお変えて

210
00:24:47,330 --> 00:24:50,688
Hudsonのディレクトリを開く

211
00:24:50,688 --> 00:25:08,481
見えるかな？

212
00:25:08,481 --> 00:25:14,364
Hudsonは他のJavaプログラムと違ってコンテナやTomcat無しで

213
00:25:14,364 --> 00:25:19,731
5000の依存関係をコンパイルしたりしなくても

214
00:25:19,731 --> 00:25:24,233
1ファイルをダウンロードして実行できる

215
00:25:24,233 --> 00:25:28,263
インストールに何時間もかかってTomcatを入れてなんて

216
00:25:28,263 --> 00:25:38,447
事も前にあったけど

217
00:25:38,447 --> 00:25:44,257
これでローカルでHudsonが動いている

218
00:25:44,257 --> 00:25:49,089
localhostの8080にアクセスして

219
00:25:49,089 --> 00:26:01,992
おっと

220
00:26:01,992 --> 00:26:09,539
(.comを指摘されて)みなさんのほうが賢いみたいだ

221
00:26:09,539 --> 00:26:14,835
これが僕のマシンの上のHudson

222
00:26:14,835 --> 00:26:28,648
この画面でHudsonの管理ができる

223
00:26:28,648 --> 00:26:33,549
ビルドの履歴をプロジェクトリストから見たり

224
00:26:33,549 --> 00:26:43,839
最後にテストが失敗したか成功したかが見れる

225
00:26:43,839 --> 00:26:53,145
これはプロジェクトの例

226
00:26:53,145 --> 00:27:03,555
テストのプロジェクトを作ってみよう

227
00:27:03,555 --> 00:27:16,255
フリースタイルプロジェクトを選んで

228
00:27:16,255 --> 00:27:34,451
gitリポジトリを使う

229
00:27:34,451 --> 00:27:48,588
このブランチを使って

230
00:27:48,588 --> 00:27:53,887
手動でビルドしたり定期的にビルドしたり　SCMから呼ばれたりもできる

231
00:27:53,887 --> 00:27:57,054
実行するシェルの設定

232
00:27:57,054 --> 00:28:05,300
cakeのコンソールを使ってテストを実行

233
00:28:05,300 --> 00:28:18,304
コアのヘルパーのテストを実行するようにする

234
00:28:18,304 --> 00:28:25,777
メールの送信を設定

235
00:28:25,777 --> 00:28:29,968
誰かメールを受け取りたいかい？

236
00:28:29,968 --> 00:28:53,110
誰もいない？　じゃあグラハムだ

237
00:28:53,110 --> 00:29:01,966
ビルドが失敗する度に君にメールを送る

238
00:29:01,966 --> 00:29:05,553
ビルドを壊した人にメールを送るなんてのもあるね

239
00:29:05,553 --> 00:29:14,095
これでプロジェクトは設定できた

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

241
00:29:19,126 --> 00:29:32,172
これで壊した人が責任をもって直すようになるね

242
00:29:32,172 --> 00:29:44,449
実にすばらしい

243
00:29:44,449 --> 00:29:47,287
ビルド中だね

244
00:29:47,287 --> 00:29:49,971
♪

245
00:29:49,971 --> 00:29:53,280
Hudsonには複数のプロジェクトを作成できる

246
00:29:53,280 --> 00:30:00,070
Hudsonはリポジトリからローカルにコードを持ってきて

247
00:30:00,070 --> 00:30:04,306
指定されたコマンドを実行する

248
00:30:04,306 --> 00:30:09,810
cakeコマンドとか必要なら他のコマンドも先に実行できる

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

250
00:30:18,251 --> 00:30:23,684
exitステータスが成功ならビルドも成功

251
00:30:23,684 --> 00:30:30,462
コンソールのアウトプットを見てみよう

252
00:30:30,462 --> 00:30:34,543
githubからクローン中だね

253
00:30:34,543 --> 00:30:38,473
時間がかかりそうだ

254
00:30:38,473 --> 00:30:54,266
(ネットワークが不調)失敗しそうだ

255
00:30:54,266 --> 00:30:58,248
ビルド失敗だね

256
00:30:58,248 --> 00:31:04,622
1分前に失敗　グラハムにはメールが届くはずだ

257
00:31:04,622 --> 00:31:12,032
設定を変更

258
00:31:12,032 --> 00:31:20,011
(ローカルのリポジトリに変更)

259
00:31:20,011 --> 00:31:32,683
これで動くかな

260
00:31:32,683 --> 00:31:42,132
ディレクトリ名で動くらしい　グラハムによると

261
00:31:42,132 --> 00:31:51,754
実行中だ

262
00:31:51,754 --> 00:32:04,231
ネット接続が面白い事になってるね

263
00:32:04,231 --> 00:32:15,614
失敗だ

264
00:32:15,614 --> 00:32:26,124
ネットワーク接続があればなー

265
00:32:26,124 --> 00:32:34,568
遅いな

266
00:32:34,568 --> 00:32:47,223
やっぱり繋がってないな

267
00:32:47,223 --> 00:32:53,413
本来ならここにビルド成功を示す青いラインがでる

268
00:32:53,413 --> 00:33:00,604
ちゃんと動いていればね

269
00:33:00,604 --> 00:33:25,191
コンソールにテストの内容と結果が表示される

270
00:33:25,191 --> 00:33:31,027
グラハム　メールは来た？

271
00:33:31,027 --> 00:33:40,241
これで発表は終わりです

272
00:33:40,241 --> 00:33:50,208
質問があればどうぞ　時間は大丈夫？

273
00:33:50,208 --> 00:34:01,778
HudsonでSereniumは使えるか？　使えるよ

274
00:34:01,778 --> 00:34:11,606
PHPUnitからSereniumを実行しているかSereniumRCを使ってブラウザを動かしていれば

275
00:34:11,606 --> 00:34:15,919
ちょっと設定は面倒だけど

276
00:34:15,919 --> 00:34:24,996
PHPUnitからSereniumを実行して結果をチェックする

277
00:34:24,996 --> 00:34:31,380
HudsonがPHPUnitを実行してPHPUnitがSereniumを実行して Sereniumがブラウザを実行し

278
00:34:31,380 --> 00:34:35,996
PHPUnitがテストが失敗したかどうかを伝える

279
00:34:35,996 --> 00:34:40,197
これで回答になったかな？　OK

280
00:34:40,197 --> 00:34:48,514
何が動かないか？　設定が面倒だけど

281
00:34:48,514 --> 00:34:58,546
依存関係も多くないし

282
00:34:58,546 --> 00:35:22,092
Hudsonはユニットテストフレームワークには関与しない

283
00:35:22,092 --> 00:35:30,416
単にコンソールを見るのでSimpleTestでも問題ない

284
00:35:30,416 --> 00:35:34,339
Hudsonのコンソールを見ればわかるけど

285
00:35:34,339 --> 00:35:42,063
何が実行されてどうして失敗したのか

286
00:35:42,063 --> 00:35:44,676
OK

287
00:35:44,676 --> 00:35:49,523
後ろの人

288
00:35:49,523 --> 00:36:13,812
まだ無理だね

289
00:36:13,812 --> 00:36:18,625
じゃあありがとうございました