非常に興味深いエントリーです。
hamcrestのMatcherメモ - 都元ダイスケ IT-PRESS
assertThatいいですよねー。
私も虜。JUnit4が使える開発ではassertEqual使わなくなりました。
ただ個人的には、「テスト」という意味でMatcherは
「is」くらいしか使わないほうがいい気がしてます。
テストケースとして
「actualの文字列が何とかで始まること」
とか
「actualの配列の中に何とかと何とかが含まれていること」
というのは単体テストのテストケースとしては弱い気がしてて。
メソッドの責務や粒度を考えて
「actualが何とかであること」
というのを定義していくことで、安心できるテストケースができるのではないかと。
notとかいれちゃうと定義の幅が広がってどこまでテストしなきゃいけないのか迷子になっちゃう。*1
Matcherを凝るよりは、
単純な比較をつらつらとまとめ
↓
とっととテストクラス完成させて
↓
実行
ってルートが個人的には良いです。
で、結合試験とかで見つかったバグは、テストクラスに不足してたからってことで
テストクラスにテストケースを追加していく感じ。
まぁ、テストのやり方に絶対的なものは無いので、自分のやりやすい方法を見つけることが
「テストしよう」と思い＆実施する秘訣やも知れません。
*1:「nullでない」とかは良いけど、「AとBを含まない」的なものは「Cであること」と書いたほうがテストケースもぶれないと思うのです
