今更ながらTDDBC Tokyo 2013

メモがあったので乗っけとく

TDDBC TOKYO
twada和田拓人
gihyo.jp
動作する綺麗なコード…
動くー綺麗か？

②つの道がある。
１．汚い・動かない→※②汚い・動く→綺麗・動く
２．汚い・動かない→※①綺麗・動かない→綺麗・動く

※①綺麗さには限界がないので、期限に間に合わなくなる。
　完璧主義沼地。
　ソフトウェア開発手法はまだまだ未熟。
　→動かして初めて分かることのほうが多い。

※②堕落沼に落ちる。
　コードを綺麗にすることを怠ってはいけない。

２．のほうがTDD。

TDDとは？
　目標を考える（TODOリスト。設計リストを作成。)
　作業を選択する。
　RED,GREEN,REFACTORのサイクルを回す。
　　→つまり２．のサイクルを繰り返す。
　　　何をしてるのかを常に意識することがアジャイルでは大事！
　矢印があるということは目的がひとつということ。
　
　GREEN…取りあえず動くコードを書く。【汚くていい】。
　Refactoring…小さいうちに片付ける。
　　リーダブルコード、リファクタリングの有名なやつ
　　2冊本がおすすめ。

大事なこと１．
　大きい問題をそのままテストするのではなく、
　小さい問題に分けて、それを組み合わせて
　大きい問題を解くようにする。
大事なこと２．
　サイクルを素早く、回数を行う。
大事なこと３．
　自分が最初のユーザである
　(自分が作るものをまず初めに自分が使う。)
　　→テストコードで使う。
大事なこと４．
　【不安なこと】をテストする。
　　→不安でないことはテストしない。
　　　getter,setterにはいらんでしょ？

TDDのメリット
　ソフトウェア工学的なメリッドもあるが、最大の理由は
　【心理的なもの】【健康】
　　→即座にフィードバックが得られる
　　→書いたコードに自信をもつため
　　→これから書くコードに自信をもつため

　健康なら毎日REDBULL＋終電ダッシュはしなくていい。

TDD採用(MS,IBMの例)
　管理者見積もりによる増加コード実装時間
　　15%~35%
　テストコードはプロダクトコードの30%〜90%

　コーディング行・時間は増えるが、
　デバッグの時間が減るので全体の時間は減る。
　　デバッグにかかる時間はブレが大きいが、
　　そのブレを抑える働きがある。

TDD応用
　テストのないコードがたくさんある…
　　レガシーコード改善ガイド本
　すでにデータの入ったデータベースがある…
　　データベースリファクタリング本
　SlowTests…
　　メモリに対するテストより、DB、ネットワークに対する
　　テストのほうが時間がかかる。
　　→フィードバックにかかる時間が増えてしまう。
　　xUnitTestPatterns本…英語
　　　ネットのwikiをまとめたもの。
　テストをどこまで行えばよいか・何をテストすればよいか…
　　ソフトウェアテスト技法ドリル本
　実際の複雑なテストをどう行うか？
　　実践テスト駆動開発

TDDはスキル！
　才能ではなく習得可能！
　量は質に変化する！
　写経！！

**********************
実践テスト駆動開発の著者の一人
スティーブフリーマン(Steve Freeman)

　新しい機能を追加するのではなく
　既存の機能をリファクタリングすだけなら
　リファクタリング用のテストコードを書いて、
　リファクタリングを行う？

　●テストダブルを行う理由は？
　オブジェクト間のメッセージが飛びかっていて、
　(オブジェクトが頂点でメッセージが辺のようなグラフ)
　　その中のやり取りが上手くフィットしているか
　　確認するってのが１０年前に言われて、
　　今もそれが目的だと思っている。

　　テストを細かくするため。
　　たくさんエラーが出た時にどれが問題かを判断するため。

　●不可能なテストをどのように対応するか？
　　　→レガシーコード改善ガイド本見て。
　　依存関係を切っていく。
　　大きな塊でやっていく。
　　
　小さく取り出して安全な形で変えていく(リファクタリング？)
　そのうち状況が変わったり、
　解決につながるアイディアが思い浮かぶ。

和田問写経

Githubリポジトリ
TDD伝道師の和田さんが出された問題が話題になったのでやってみた。
というか、黒魔法リフレクトを唱えるのもめんどくさくて、
解説見てから良さそうなやつを実践した。

解説で問題を解くパターンがたくさん紹介されているので、
それぞれメリット・デメリットがわかりやすくてとてもタメになります。

私が今回実践したのはSelf Shunt。
わかりやすく実践しやすい上に強力。

脆いテストにならないように注意して多用しようと思う。

〜追記〜
Junit4でテストクラスで継承を行った場合に下記例外が発生した。

java.lang.Exception: Test class should hava exactly one public zero-argument constructor

どうもテストフレームワーク側で引数なしのコンストラクタを使用しているため、
引数ありのコンストラクタのみしかない場合に例外になるようだ。

プロダクトコードに引数ありのコンストラクタしかない場合はSelf Shuntは使用不可なのか？