テストコード書いてますか？ HIROKIです。
murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。
1．テストが重要だという共通認識を持つ。
前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。
その経験を元にテストが重要だという共通認識を持つことができました。
2．プロジェクト開始時からテストファーストに踏み切る気持ちが必要
テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。
3．でも、テストコード書いたことないよ？
テストコードを書いたことのないメンバーもいるかと思います。 そんな人は下記の参考書を写経することから始めましょう。
symfonyを使うことが前提だったので、上記の本をlimeで置き換えて写経しました。
また、下記のような動画もとても参考になります。
- ruby札幌 スはスペックのス〜RSpecによるテスト駆動開発の実演〜 その1 その2 その3
- ［動画で解説］和田卓人の"テスト駆動開発"講座
4．そんなこと言っても、自主的に学習する人ばかりでないよ？
初日にペアプロしちゃいましょう。
そのチームでTDDに一番詳しい人と、TDD初心者な人をペアにして、 実装を始める初日かその前（できるだけはやく）にペアプロをしましょう。
ペアプロは1モジュール書き上げるくらいが良いかと思います。 そのチームで利用する開発環境の基本的なテストコードの書き方として後に参考にします。
私のチームではsymfony+memcached+lime+hudsonという環境でしたので、 どのタイミングでfixtureを流してmemcachedをクリアして、 どういったテストの書き方をしていくのか参考になるものを1つ作り上げました。 (細部に関してはチームみんなの意見をあつめて、検討してつくりました。)
これができれば他のモジュールにも適応して開発していくだけです。
5．じゃあ、やってみた経験から為になること教えてよ？
symfonyでテストファーストを実施してみた経験から具体例をあげてみます。
fixtureを理想的なものを最初につくっておく
テーブルの定義だけではなくて、 テーブルの中身のサンプルを全部のテーブル用意しておくこと。 データ自体は簡単なデータでよい。
モジュールをつくる度にあらたなfixtureをつくることを避けられる。 fixtureをつくるのが結構めんどくさい。 テストを書きたいのにデータがないというフラストレーションがたまる。 結局、つくらないといけないけど、他のモジュールで使っているfixtureと整合性がとれているのか？
規模が大きくなればなるほど、面倒なことになります。
limeのOKメソッドは使うな
bool値をチェックするメソッドとしてokメソッドがLimeには用意されていますが、 これを使用することを非推奨としました。
たとえば、テストが失敗したケースを考えると。
$test->ok(false);
実行画面
not ok 21 # Failed test (./hogeTest.php at line 34)
という感じで返ってきます。ですが、isメソッドで書けば
$test->is(false,true,trueが返ってくるはず);
not ok 22 - trueが返ってくるはず # Failed test (./hogeTest.phpat line 35) # got: false # expected: true
という感じで出力が返ってくる。コメントもあるので、わかりやすい。
okメソッドだけだと情報が少なくて苦労するケースがあるので、面倒でもisメソッドで書くことにしました。
コメントではなくて、コードに含めろ
非推奨
// trueが返ってくるはず $test->is($foo->bar(),true);
not ok 22 # Failed test (./hogeTest.phpat line 35) # got: false # expected: true
推奨
$test->is($foo->bar(),true,trueが返ってくるはず);
not ok 22 - trueが返ってくるはず # Failed test (./hogeTest.phpat line 35) # got: false # expected: true
コメントを元にテストの場所や書いたテストの意図がわかるので、メソッドに含めましょう。
まとめ
このグラフがhudsonが1回目のビルドから529回目のビルドまでのテストにかかった時間と成功・失敗の結果です。
チーム全体で常にすべてのテストをパスしている状態を保つという意識とそれに伴う行動の結果です。
Files=59, Tests=3152
現時点で59ファイル、3152のテストをパスしています。
赤色の部分も目立ちますが、テストが成長していることが目で見てわかります。 こうやって、テストに支えられていることも再認識することも大切なことなのかな。とも思います。
今回は、チームでテストファーストをやるためのステップと、少し具体的な例を紹介してみました。