TDD Pre Camp 大阪行ってみた。

Java TDD

来る６月初頭のTDDBC大阪に向けて素振りしに行ってみました。

感想：
TDD Pre Camp 大阪は辛かった。

いや、ガチで辛い。ほんと辛かったです。


こういう理由で。


[twitter:@pocketberserker] さんと一緒に虚空を見ましたが、良いコードが見えるような第六感には恵まれませんでした。
なんていうか胃がちょっと辛(つら)い。
どうしてこうなった。マジックスパイス恐ろしい子。


閑話休題。
素振りで出来上がったコード。
まだまだリファクタリング出来ますし、なんか仕様間違っているところもあったりと色々ひどいコードですが。
20120430TDDBC_PRE_CAMP_OSAKA
(何より一番ひどいのはColaというクラス名かw)


とりあえず、今日行った理由は以下の二点を確かめるためです。
・オレオレでやっている自分のTDDの方向性は合っているのか？
・他の人はどのくらいのテストの粒度（一つのテストメソッドでどのくらいassert突っ込んで)やっているのか？
デザインパターンしかり、アジャイル開発しかり、オレオレでやっていると「ほんとにそれで合ってんの？」という不安にとらわれがちです。
「不安をテストに！」の精神で素振りしに行ってみました。


素振りしてみてわかったのはだいたい方向性は合っていたような気がします。
ただ、細かい点においてはまだまだ議論の余地があります。
例えば自分の場合は「不安に思ったところ」という原則に加えて、「printデバッグ入れてオブジェクトの状態を確認したいな。」というところにassert突っ込む感じでやっているので、当然複数のassertが一つの入る場合もあります。
これをシナリオ的なテストと定義するか、TDD的なテストと定義するかというあたり等々。

@Test
public void 投入されたお金以上に売ってはいけない(){
	try{
		sut.receve(100);
		sut.sell(3);
		fail("投入金額以上に売っている。");
	}catch(IllegalArgumentException e){
		assertThat("投入金額以上に売っています。",is(e.getMessage()));
		// 当然在庫も減らない。
		assertThat(sut.stock(),is(5));
	}
}


後、改めて確認できたのは
・誰のためのテスト？ → 俺のため。
・品質は保証できるの？ → 俺にとっての品質は保証できる。お客にとってはしらん。
・それっていいの？ → 俺の健康のにはすこぶるいい。
まずはそのくらいの緩い感じでおkだということ。
突き詰める議論はあとでも出来るのでまずはやってみる。それが大事。


なので、例えばI/OとかマルチスレッドとかTDDしにくいところは無理にする必要はなく、出来るところからやっていけばいいというスタイルで大丈夫でした。
逆に、TDDしやすいようにクラス設計した方がJavaの場合はよりオブジェクト指向っぽくなるんじゃないのかなとか、TDDで出来ないということがわかるが故に別のテストの方法を切り分けれるとか、もっと設計を堅牢にしたり、APIを利用することでテスト不要にしてしまうとか、気づくところはたくさんあったり。


いろんなコード、書籍、スライドを参考にして6月のTDDBCに向け更に理解を深め6週目くらいには間に合うように精進します。


主催の
[twitter:@pocketberserker] さん
[twitter:@irof] さん


参加者の
[twitter:@zuq9nn] さん
[twitter:@yalab] さん
[twitter:@shinsukeoda] さん
[twitter:@hakurai] さん
[twitter:@koko_u]
[twitter:@fishiiiiiii] さん


おつかれさまでした。




追記。
アガリ症なのでカタカタ震えながらコーディングしてたのは僕と君との秘密！
発表のときにswich文をSet#containsでリファクタリングして俺カッコイイするの忘れてたなんて言えないよ！