shimitei blog

テスト駆動開発はよく知らないけど、
・今やるべきことにフォーカスする
　ユニットテスト先に書いてREDからGREENにする
・ユニットテストがあるからリファクタリングしやすい
的な良い習慣というイメージだった。

もっと厳密なルール付けとか、テストコードを実装コードでテストするようなテクニックがTDDにはあるようだけど。

実習はペアプログラミングなのでTDD初心者でもOKな感じ。
コードレビュータイムもあったけど、時間がなくてカットされてしまった。
せっかくなのでもう少し解いてGitHubにあげておく。C#とMsTest。
https://github.com/shimitei/csharp-mstest

他の人のコードレビューを見ると、golangはテストの実行が瞬時に完了して良い。
LTではSpockでのユニットテストがいい感じ。従来のテストフレームワークで気になるところが解消する。

TDDの暗黒面は、TDDが悪いわけではないがもっと優先すべきことがあるのではないかな。
設計・優先順位付けとかコーディングがうまくできていないと、結局技術的負債はたまる。
安易な設計でテストファーストにすると手戻りが発生してしまうし、何故かコードを複雑にしたがる人がいる。
安易でもさっさとすすめて問題にぶち当たって解決してのパワープレイができれば苦労しない。
TDDは設計やコーディングのさじ加減をうまくできる人には向いているけど、そうでない人は延々と時間を吸い取られるのでペアプログラミングしかないのかな。

今回のお題は数学的な概念で仕様がいきなりひっくり返ることはないため、インクリメンタルな開発に向いている。
最初は純虚数で次に虚数、ガウス整数が来る。純虚数と虚数を同じクラスにするか別のクラスにするか、最初の純虚数クラスを複雑に作りこんでしまうかでも手間が変わってくると思う。

というわけで、TDDをKeepしつつDDDにTryするのがよさげ。