TDDMeetUP[2013/6/17 (Mon) 16:30-]に参加してきました。
参考:http://togetter.com/li/520008
参考:http://www.slideshare.net/KyonMm/unittesttdd-tddmeetup
初勉強会だったのですが感想を書いてみます。
(うまく表現できない上に主観が多いので要注意)
「UnitTestは最もTDDしやすいテストであるかについて本気で考えてみた」
を聞いて着眼したキーワードはこの辺
・TestLeve テスト対象物の粒度
Unit->Component->Integration->System より難しく、遅くなる
・外部仕様と内部仕様を分けるTDDもある
UnitTestは内部仕様、外部仕様はIntegrationレベル
・TDDは開発支援フレームワーク
・入門TDD(Kent Beck)はTDDフレームワークの実装例
・ストーリー受け入れTDDでは最低2つの正常系と1つの異常系は必要
発表が終わった時点でも質問させてもらったのですが、
まず思ったのはきょんさんの捉えるTDDはI/F設計なんだなぁと。
そう見方を変えると今まで不思議に思っていたことがほぼほぼ解決しました。
参加前までもやもやしてたこと
・外部仕様レベルをどうやってTDDできる単位までうまく分割するか
・大きな階層と小さなテスト書きやすい階層をうまくつなげなくて中身の薄い階層が出来てしまう
・状態遷移のテストを書くのが難しい
・TDDとUnitTestのコードは分けた方がいい?
これらは全てTDD=>Integration,I/F設計と考えるとそもそもスコープ外だったことがわかります。
UnitTestをTDDで綺麗に書けるはず!ともやもやしてたんですよね、今まで。
きょんさんと話していて感覚にズレを感じた部分は他にもあって、
きょんさんは「TDDでダメコードを防ぐ」といったニュアンスの発言をしています。
これって自分も『入門TDD』を斜め読みしながらTDDに期待していた部分なんですが、
よくよく聞いてると"コード"に対する捉え方が少し違うと思うんですね。
自分が"コード"が綺麗汚いとか言われると「ネストし過ぎ」みたいな
レガシーコードっぽい文脈で出てくるような部分のことを想像するのに対して
きょんさんの場合は内容を把握しやすいメソッド名とかテストしやすいI/Fみたいな
I/F周りのことを特に意識して"コード"と言っている気がします。
うまいI/F設計が出来れば自ずとコード内容も導かれるだろうということかな。
関数型とか使うと特にそういう思考になりやすいんだろうかと勝手に想像してみる。
最初の発表で妙に納得してしまったので以降のセッションの部分は、
納得部分の補足裏づけみたいな感じで聞いてるだけになってしまいました。
・性能のために汚いコードを書くかどうか
ギリギリまではTDDで理想のコードを書いて実際に性能はかってから
必要に応じて書き換えればいいのでは、という話。
これもTDDがI/Fメインの話と考えれば、それより小さい単位の部分は
技術的に差し替えるのは可能ということですね。
・関数型Haskell/OCamlでは型でチェック出来ることが増えるのでテストコード自体は減少する
自分は関数型に全然触れたことが無いのでどこかでは勉強してみたいです。
・RED->GREENの間隔
AutoSaveにしてファイル変更で自動テスト回すようにして間隔をチェックする。
赤が長いと問題を放置しすぎ。緑が長いのも適切にリファクタされてない。
といった指標にできるという話。
IntelliJで開発すると1文字でも動作しちゃいますね:P
「1byteでも変更するならテストを書け!」(誰の言葉だっけ、、、)
・モックの功罪の話
嫌い派
・面倒
・バグの作りこみ
・メンテナンスコスト
好き派
・腐敗防止層
・捨てる前提のモック
・TDDの自殺
好き嫌いに関わらず、けっこうモック作りこんでる事多いのかな?という印象。
自分は今のプロダクトはJMokit使って書いてて複雑なモックは書いてないですが、
テスト対象たりえる戻り値がモックコードでいいんだろうか?と思うことが多いので
この辺はI/Fに「何をテストしたいか」の視点が抜けてるせいだと
勉強会後は思っています。
最後はATDDの話とか出ていて、早く自分もGOOS読まねばと思った次第。
自分なりの誤解が解決したので非常に得るものの多い勉強会でした。
みなさん、ありがとうございました。