#php_tdd_ci に参加して知った仮実装の付加価値と、例外処理のプラクティス

48JIGEN Reloaded

#php_tdd_ci に参加して知った仮実装の付加価値と、例外処理のプラクティス

2011/06/21

ラーメン食べたい。

今週末に食べる地元札幌、大心のラーメンが楽しみで楽しみで震える@remoreです。 ※本文と写真は関係ありません

昨日GREEのセミナールームで行われた「PHPでTDD&CIワークショップ」に参加させて頂いて、本当に光栄にも@t_wadaのFizzBuzzを書くデモのペアプロパートナーをやらせて頂きました。帰宅したけどまだ手を洗えない状態です。※握手はしていません ※オーラか何かがまだ残ってる

さて、~~会場でRedbullをうっかり2本も飲んだせいで~~色々と学びの多かった勉強会だったので興奮が覚めず寝れそうにないので、今日学んだことを書き残しておきます。内容はいまTDDを勉強している人向け。

テストコードをテストできる。仮実装の付加価値

仮実装ってご存知でしょうか。こんな感じのコードの事です。

function func_plus($a, $b){
  return 10; // 仮実装：一旦定数を返しておく
}

class MyTest extends PHPUnit_Framework_TestCase
{
    public function test_テストコードの例(){
      $this->assertEquals(10, func_plus(3, 7));
    }
}

「仮実装」という言葉はケント・ベックの「テスト駆動開発入門」に出てきて、昨日@t_wadaも使っていたので、TDDをする人の間では使われる用語なんだと思います。

さてこの仮実装ですが、「テスト駆動開発入門」ではレッド・グリーン・リファクタリングのTDDのリズムを素早く刻むための戦略として紹介されているのですが、@t_wadaは「仮実装は同時にテスト駆動開発の重要なトリックをもたらす」、と紹介していたのが大変勉強になりました。

それは、仮実装によってテストコード自体をテストできるという付加価値が生まれるという言及です。つまり、一旦定数を返す仮の実装を行うことでテストコードに対して完全に正しい振る舞いをするようにした上で、xUnitを動かしてグリーンにする（テストをパスさせる）というプロセスを経ることで、振る舞いを検証しているテストコード自体が正しく書けていることを検証できる、そしてこれはテストを実行可能なコードの形で書いているからこそ得られるメリットであると解説していました。

「テスト駆動開発入門」を一回読んだ限りの理解ですが、僕は今日勉強会に参加するまで、TDDの仮実装のプロセスにこんな付加価値があることに気付いていなかったので、大変勉強になったという次第です。（本の中でこの事に言及した節はなかったような気がするのですが、実は書かれていたのかな。ご存知の方いらっしゃったら、@でmention頂けると助かります）

例外処理のプラクティス

昨日のペアプロのソースコードレビューの時に出た話題で、PHPUnitのマニュアルでも丁寧に解説してくれていますが、例外処理の2種類の書き方って、try～catchを使う方法と、アノテーションを使う方法の2種類あるじゃないですか。（setExpectedException()を使うやり方もありますが、読み易さを重視して一旦アノテーションで紹介）

これまでお好みでどっち使っても良いと思ってたけど、@t_wadaから上手な使い分けのプラクティスを紹介してもらって目から鱗だったので、こちらも紹介しておきますよ。

テストコードが複数行にわたっている場合に、try縲彡atchでかなり的を絞った書き方ができる

例えばこんな感じで、例外が発生すると思われる箇所をテストコードで明示できるというところがコツ。

class MyTest extends PHPUnit_Framework_TestCase
{
    public function test_例外が起こるテストケース(){
      init();
      validate($something);
      // ここまでは例外が発生しないはず。次から例外をチェック
      try{
        func_hoge();
        $this->fail();
      } catch (InvalidArgumentException $e) {
        $this->assertEquals("error message", $e->getMessage());
      }
    }
}

また、@expectedExceptionアノテーションとは違って例外の中身までチェックできるというメリットもある。

シンプルな例外発生確認であれば、@expectedExceptionアノテーションがベター

@expectedExceptionアノテーションはtry縲彡atchの方法とは違って例外発生の的を絞れないものの、テストコードを簡潔に書けるので、可読性がとても高い。可能な場合は（例外発生の的を絞る必要がない場合、つまりテストコードが１行で収まるなどの場合は）こちらで書いた方が後から見通しがよくなる。

class MyTest extends PHPUnit_Framework_TestCase
{
    /**
    * @expectedException OutOfRangeException
    */
    public function test_例外が起こるテストケース(){
      func_hoge();
    }
}

２通りの方法のメリット・デメリットを理解して上手に使うべきとのことでした。

Jenkins CIのコツ：困ったらJenkins wikiを調べる。

帰り道で、@cactusmanに教えていた秘伝の技です。Jenkinsで困ってgoogle調べてもなかなか情報少ないんですよねー、ってぼやいてたらJenkins wikiにけっこう情報が書いてあります、と教えて頂きました。で、アドバイスに従って実際業務で困っていた内容を調べたら簡単に見つかったという。こういうコツってネット見てるだけだとわからないので、本当に助かりました！

というわけで、とても充実した時間を過ごさせて頂いた勉強会でした。主催の@tsuyoshikawaさん、講師をして頂いた@t_wadaさん、@cactusmanさん、@yamashiroさん、参加者の皆さんお疲れ様でした＆ありがとうございました！！

またTDDBC in Tokyoやその後のイベントでお会いできるのを楽しみにしています。