ほげほげ見聞録

技術メモ、備忘録、使い方はそのうち覚える

「テスト駆動開発」読書会 Vol.7 に参加した

以前の記事に書いたように開発にTDDを取り入れてみたが、いかんせん一人でやっているので分からない部分が出てきた。
dwmemo.hatenablog.com
どうしたものかと思っていたところ、以下の勉強会を見つけたので参加することにした。
hiro-o.connpass.com

勉強会は、時間を区切って本を黙読・議論するという流れが決まっていて初参加でも気楽だった。
この記事では勉強会で知ったことなどをメモしていく。

テストの長さについて

入力項目の多いフォームをテストする際、バリデーションだけでテストクラスが大きくなり…他の項目も含めると結構な大きさになる事に悩んでいた。
これは自分の勝手な思い込みだった。テスト対象とテストクラスは一対一になっていなくても良いとのこと。
PHPUnitで実際に分割するときは、以下のようにしたらスッキリした。

  • テスト対象クラスと同じ名前のフォルダを作成、項目ごとにテストクラスをファイル分割
  • 各テストクラスには@groupで共通の名前を付けておく

例外のテストだとアサーションがないテストになる?

アサーションがないテストは良くないと言われているそうな。
http://bliki-ja.github.io/AssertionFreeTesting/

本書の第29章「例外のテスト」では、例外が発生しない場合はfail()を使っている。
例外の場合はアサーションがなくてもいいのではとのこと。

PHPだとアノテーション「@expectedException」を使うと簡単になる。

/**
* @expectedException Exception
*/
public function test_hoge() {
    Test_Class::throw_exception();
}

https://phpunit.de/manual/current/ja/appendixes.annotations.html#appendixes.annotations.expectedException

privateメソッドのテスト

本書で著者はpublicな振る舞いのみでテストを書くべきと主張している。
自分はprivateもテストしておいた方が良いだろうと思いReflectionを使っていたが、privateメソッドはpublic経由でテストすれば十分だとの事。
どうしてもprivateをテストしたい場合は、別のクラスに抽出するなど対応した方が良いかもしれない。

他のメンバーにもTDDやってもらうには

時間がなくてテストを書かないなら可能性はあり。
時間があってもテストを書かないなら可能性なし。
とのこと。