『JUnit実践入門』写経・実践会 in 横浜 #3 に参加して来ました。 #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #3
http://connpass.com/event/1668/

2013/02/02 『JUnit実践入門』写経・実践会 in 横浜 #3 #junitbook
http://togetter.com/li/448707

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook

今回は「Part.3 ユニットテストの活用と実践 第11章 テストダブル」が対象でした。
範囲はそんなに広くなかったので、写経は早めに終えることが出来ました。
なので、Groovyで書いた場合を試してみました。

レポジトリはこちら→https://github.com/grimrose/junit-boost-camp

一つどうも動かない箇所がありました。

MethodExtractExampleTestをGroovyで書くと失敗してJavaで書くと成功する…なんでやろ… #junitbook
— とーますさん (@grimrose) 2013年1月27日

デバッガーで見てみた時

デフォルトコンストラクタ呼び出し時のDate date = newDate()でnewDate()が呼ばれた時にcurrentがnullだから落ちてるのか…ってなんでcurrentがnullなんだろ…
— とーますさん (@grimrose) 2013年1月27日

GroovyのmetaClassを使ってみたコードはこちら

	package chapter11
	import org.junit.Test
	import static org.hamcrest.CoreMatchers.is
	import static org.junit.Assert.assertThat
	class MethodExtractExampleGroovyTest {
	@Test
	void "doSomethingでdateに現在時刻が設定される"() {
	// Setup
	final Date current = new Date()
	MethodExtractExample.metaClass {
	newDate = {
	println("call expanded.")
	current
	}
	}
	MethodExtractExample sut = new MethodExtractExample()
	// Exercise
	sut.doSomething();
	// Verify
	assertThat(sut.date, is(current))
	}
	}

view raw MethodExtractExampleGroovyTest.groovy hosted with ❤ by GitHub

どうも、Interceptしてないみたいです。

次のDelegateObjectSampleTestでは、エラーにならなかったので、多分そうかと。

	package chapter11
	import org.junit.Test
	import static org.hamcrest.CoreMatchers.*
	import static org.junit.Assert.assertThat
	class DelegateObjectSampleTest {
	@Test
	void "doSomethingを実行するとdateに現在時刻が設定される"() {
	// Setup
	Date current = new Date()
	DelegateObjectSample sut = new DelegateObjectSample()
	sut.dateFactory = new DateFactory() {
	@Override
	Date newDate() {
	current
	}
	}
	// Exercise
	sut.doSomething()
	// Verify
	assertThat(sut.date, is(sameInstance(current)))
	}
	}

view raw DelegateObjectSampleTest.groovy hosted with ❤ by GitHub

余裕があるときにもう少し突っ込んでみたいと思います。

リファクタリング

ディスカッションの際、privateメソッドをテストするかという質問が挙がったのですが、
突如参加してくださった@t_wadaさんのお陰で、納得することが出来ました。
個人的には、privateメソッドの処理を別のclass(大抵パッケージプライベートのstatic class)として切り出して、
Quick JUnitでテストクラスを作成します。

そうすれば、黒魔術を使うこと無く呼び出し元のメソッドをテストすることが出来ます。
オブジェクト指向養成ギブスとは違う異質な縛りがあるようなプロジェクトもあるそうなのですが、そんなピヨピヨなプロジェクトでも、自動テストと責務に応じたリファクタリングを行うことで、適切に対応できると思います。

モック、スタブ、スパイ

以前にServletRequestに依存したオブジェクトを利用したクラスのテストを実施するためにjmockitを利用したことがありました。
その時は、他のモックライブラリに比べて色々出来るのでいいのかなと思っていましたが、
今回@t_wadaさんのお話を聴いてやりすぎると痛い目に合うということと、それを経験して戻ってくるのがいいのを教えて頂きました。

他のモックライブラリでは日本語の情報がなかなかなかったのですが、今回、この本が出たお陰でプロジェクトに導入するきっかけになるのではないかと思います。

おわりに

今回は、@t_wadaさんのお陰でモックを利用したテストに対してモヤモヤしていた箇所が少しづつ晴れてきたように感じました。
それに、監訳された「SQLアンチパターン」にサインを頂くことも出来ました。

主催の@shinyaa31さん、突然の参加で講師役？までされた@t_wadaさん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。