読者です 読者をやめる 読者になる 読者になる

日々常々

ふつうのプログラマがあたりまえにしたいこと。

assertEqualsよりassertThatが好きなわけ

元ネタ*1は「xUnitよりRSpecがいいとか言ってたひとは英文ぽいのがいいとか言ってたけどさー」みたいな感じでしたが、xUnitであるところのJUnitでも最近は assertThat なんてもんが入って英文ぽさを売りにすることもあったりなかったり。

ツイートでも言ってる通り、英文ぽさなんてどうでもいいと思ってます。可読性は大事だけど、読めるならそれ以上は要らない派。ならば決め手は何だ。書きやすさと、エラー時の表示です。

assertEqualsのばあい

こんな感じに書きますね。短い。書く量が少ないのは良いです。でも1番目と2番目どっちがどっちだったか。

assertEquals(expected, actual);

失敗したとき出るメッセージ。

org.junit.ComparisonFailure: expected:<[expected]> but was:<[actual]>
	at org.junit.Assert.assertEquals(Assert.java:123)
	...

わからなくはない。でも assertEquals は同値性をみるものなので、引数二つは同じ型が入る。同じ型の引数を二つ並べるってことは、間違えやすい。よく間違える。そしてテストが通る限りは問題ない。こけた時に、結果を見て、逆に設定してたと気づくまでにボケてたら結構かかったりする。ちゃんと覚えたり、気をつけたりすればいい話なんだけども、そもそもそんな問題が起こらないようにする方法もある。

assertThatのばあい

その答えの一つが assertThat にあったりする。こんな風に書く。なんか is が増えた。括弧も増えた。かっこいいですね。

assertThat(actual, is(expected));

で、失敗時のメッセージ。

java.lang.AssertionError: 
Expected: is "expected"
     got: "actual"

	at org.junit.Assert.assertThat(Assert.java:778)
	...

横ではなく縦に並べるのはわかりよかったりする。

今回いいたいこと

assertThatの本来の力を引き出すにはMatcherを語らねばならないのだけど、それは置いといて……。

assertEqualsは一番目と二番目の引数の順番を間違えたりするけど、assertThatにしたら間違えなくていいよー。

番外でbooleanだけを引数にとって万能に使える assertTrue とかがありますけど、あれは何にでも使える代わりに失敗時のメッセージを見放したものです。アレ使うなら標準の assert 使って良いんじゃないかな。オプション指定しなきゃだから面倒か。

まとめ

色々書いたけどPowerAssert最強です。

*1:リンクしない