アジャイルサムライ読書会 横浜道場 「現場で実践する」に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「現場で実践する」
http://yokohama-dojo.doorkeeper.jp/events/2590

アジャイルサムライ読書会 横浜道場 「現場で実践する」 #横浜道場 #agilesamurai
http://togetter.com/li/450974

はじめに

遅くなりましたが、忘れないために書きます。

今回は、現場でいろいろとミスや失敗をしてしまいその為、遅刻して参加しました。

ディスカッション

バーンダウンチャートから見えてくる結果から、どのように計画の変更を行なっていくのかが主な内容でしたが、メンバーの増減でコストがかかる場合にあらかじめそれを見越して、ドキュメントなど後々使うのをまとめておくのは、やりたいけど優先順位下げがちだなと感じました。

自分の隣に壁があるので、ポストイットを使って自分の作業をカンバンで見える化している話をしてみました。
こういった話を出来るようになってきたのが、とりあえず一人でも出来るプラクティスをやってきた結果なのかなと思いました。
自分が実践してみて分からなかったり、疑問に思ったことを話し合える場が、外部にもあるというのは心強いです。

おわりに

togetterで見直しながら書いていますが、あとで振り返るために頑張ってtsudaって見ましたがまだまだ精進が必要だと感じました。

参加者の皆様、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。

次回もよろしくお願いします。

『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さん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。