『JUnit イン・アクション』Part1のメモ
三連休なので『テスト駆動開発入門』を写経しよかなと思ったのだけど、JUnitの知識が残念なレベルなので、先に『JUnitイン・アクション』から。このへんを目的に、写経しつつPart1まで読みました。
気づいたことやワカランことをメモします。
覚えたこと/気づいたこと
テストフィクスチャ大事
JUnitを使いこなすには、単体テストの作り方とともに、テストの足場の整備方法も習得する必要があると気づきました。
足場とは、テスト実行のための共通リソースやデータのことで、本文ではテストフィクスチャと呼ばれています。大事な要素だし、やってる人には常識の範疇かと思いますが、どうやるべきかを知らないと、案外上手くまとめたり整備したりできません。しかも、プロジェクト依存が強く、細かい話になるので、新人研修なんかで扱いづらいテーマです。
同様に、テストケースに閉じないもう少し広い意味での足場――テスト基盤を作れるようになることも、大事だと思います。たとえば、テスト用のデータベースの準備や、テストデータ復帰の自動化などです。
単体テストの可搬性、保守性、可読性
順序に依存するテストを書いてはいけないことには、テストコードの複雑さが増すからという理由以外に、リフレクションの戻り値の順序が保証されないため、という理由があると知り、納得しました。
エラーメッセージ大事
assertNull、assertNotNull、assertTrue、assertFalseを使うときは、引数がObjectだけのメソッドではなく、StringとObjectを取るメソッドを使い、失敗の理由をエラーメッセージとして書く。テストが失敗した時に原因がすぐ分かるように。
共通処理をsetUpにまとめるコツ
テストを書いてて色々疑問だったんですが、方針を得ることができました。
- ユーティリティメソッドにくくりだす。全部に共通する処理なら、setUpに移す。
- 的を絞ったテストメソッドを書く。1つのメソッドで1つのテスト。
- 足場だけを共有する。
あと、setUpで作ったオブジェクトとの競合を避ける話も、分かりやすかったです。
まだよく分からないこと
その1。インタフェースの過剰な設計を避けるためにTDDを使う、というのが、何のことだかまだ分からないので、これから勉強予定。
その2。テスト用のクラスを、テストケースクラス内のインナークラスで表現するというのも、使いどころがまだピンときません。あまりやったことがないです。
その3。「単体テストが長すぎる、単体でテストしづらい、といった状況は、テスト対象のコードの設計に問題があるサインである」という話を、もっと詳しく理解したいです。
その他
JUnitフレームワークの仕組み
JUnit内のオブジェクトのライフサイクルの説明があるので、TestRunnerクラスのmainメソッドにブレークポイントを置いて、この本を片手にデバッグ実行しながら、JUnitの実装を確認することができマス。すばらしい。
# ただ、例によって、クラスローダーまわりがまだよくワカリマセン・・・だめだ早く何とかしないと
JUnitを人に紹介するとしたら?
JUnitを人に紹介するとしたら何を中心に説明するか、という観点でも読んだのですが（自分自身が学習中のくせにアレですが、都合上…）、単体テストの書き方については、開発者個人が手を動かして覚えるべき部分がほとんどだと分かりました。
この本を紹介するのもひとつの手かな。。。何を抽出して伝えるべきか。
単体テストの意義を考える。べき。
開発者は、単体テストを行う理由と、機能テストや統合テストではなく（あるいはそれらを補うために）単体テストを作成する理由を理解していなければなりません。単体テストを作成する理由がわかったら、次は、どの程度までテストするのか、どの時点でテストは完了なのかを知る必要があります。テストをすることが最終目標ではないのです。
Vincent Massol，Ted Hustted：『JUnit イン アクション』，ソフトバンクパブリッシング，p.70，2004.5.
単体テストをしっかり学んでない≒これまで軽視してきた者にとっては、ぎくりとくる言葉です。TDDの前に、まずは「単体テストを正しく書く」という土台を固めます。
