JUnit4実践入門の感想

java junit book

JUnit4実践入門を献本してもらったので感想など。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

恥ずかしながら、僕はJenkinsでは未だにJUnit3でテストを書いています。JUnit4の新しい機能も一応は知っているつもりでしたが、こうやって系統だってまとめられていると参考になります。思わぬいい勉強をしてしまいました。


目次を見てみるとわかりますが、この本はJUnitの使い方だけではなくて、DbUnitとかAndroidのテストの話とか、MavenやJenkinsでテストをどう使うかという話にも多くの紙面が割かれていて、広範な分野に手を広げている印象です。それでいて、それでもカバーされていない話が色々あります（この点に後で少し触れます）。JUnitというかテストの分野が如何に巨大なエコシステムになっているか、改めて思い知らされます。


こういう風に巨大なフィールドでは、やれHtmlUnitという面白いライブラリがあるよとか、どうやって複雑なデータのマッチングをしたかとか、各論的な話が面白くなってきます。こういう事を議論できるメーリングリストと言うかコミュニティがあるとよいと思うのですが、そういうのはないんでしょうかね。http://junit.org/にもないのがとっても残念なところ。実にもったいない。こういうコミュニティから色々な面白いサブプロジェクトが育っていくのに。


さて、カバーされていない話があるという話をしましたが、その筆頭に挙げたいのがGroovyの話。コラムでちらっと触れられてるだけです。が、僕に言わせれば、JUnitのテストをGroovyで書かないなんてもはやありえないです。なぜなら、

  1. production codeじゃないからどんな依存関係を使っても誰にも文句は言われません
  2. Javaを使っていない人にもアプローチしやすい文法。throws節の省略とか、テストを書く時にいらない語句を削った身のしまったコードが書ける
  3. power assertのおかげでmatcherなんていらない。assertの為の新しい文法を覚える必要はない上に、診断メッセージはより親切。

    
Exception thrown
    Assertion failed: 
    assert 91 == a * b
    
          |  | | |
    
          |  10| 9
    
          |    90
    
          false
  4. 複雑なリテラルを書くのが楽。ある値をもったマップやリストを書いたり、オブジェクトのツリーを書いたり。


もう一つ、JUnit4について思うのは、無意味にアノーテーションを使いすぎってところです。例えば、@Testアノーテーション。今までみたいにテストはtestという名前から始まる...でよかったんじゃないでしょうか。その方が短いし、import文を書く必要もないし。@Test(expected=...)みたいに書きたいから一貫性のために、というのはわからなくもないですが。@Beforeと@Afterも同様。基底クラスにメソッドがあってオーバーライドする方式の方が、見つけやすいですよね。JUnit4でテストを書く時、僕は未だに習慣でsetUpとtearDownって名前にするし、この本でもそうするように勧めていますし。せっかく静的型付けがある言語なんだから活用すればいいのに。


Groovyのpower assertの方が優れているHamcrest matcherといい、なんか努力の方向が違っているように思える機能が散見されます。ruleとかいい機能もたくさんあるのですが。


冒頭の話に戻りますが、何でJenkinsで未だにJUnit3を使っているかというと、public abstract class HudsonTestCase extends TestCaseというユーティリティーコード満載のベーステストクラスがあって、これを使って書かれたテストがわんさかとあるからなんですね。このテストを全部JUnit4で書き直すわけにもいかないし。これをルールで書き直すと同じコードが２つできてしまうし。そういうわけで、JUnit3形式のテストの上に新しいruleを足す、とか、HudsonTestCaseみたいなクラスをルールとしてそのまま使えるようにするとか、そういう方向の話がぜひ聞きたいです。こういう悩みをもっている人は多そうです。


JUnitの本の話からJUnit自体の話になってしまったので話を戻します。


Jenkinsの宣伝を日本ですると、結構な数の「でもテストがないんで」という人に出会います。そういう人達にテストを書いてもらうための敷居がこの本でまた一つ下がったかな、と思います。