コードはJavaで書かれているが､Javaを書きたくなかったのでPHPで書くことにした｡
書いたコードは
にあげてあります｡xUnitからの章は『Laravel Webアプリケーション開発』を先にやりたいのでまだやってないです｡
やった感想としては､非常に狭いステップで進行するので､写経することは思っていたより難しくなかった｡テスト駆動開発を通して､ケント・ベックのようなプログラマの思考(章を進行していくごとにTodoリストが増えたり減ったりする)やコーディングの過程を追体験することができるのが良かった｡自分の環境ではまわりにいろいろと聞くことができるような凄腕のプログラマはいないので､本を通して直接教わっているような感覚を体験できる｡また章の最後に現時点でのコードが書かれているので､つまづきにくい｡
しかし､テスト駆動開発を写経して思ったのは自分にはまだ難しいということ｡
付録Cで書かれているように､
TDDのテストとは､いわばプログラミングや設計の補助線､治具です｡(p293)
TDDはテスト技法ではない｡TDDは分析技法であり､設計技法であり､実際には開発のすべてのアクティビティを構造化する技法なのだ｡(p296)
テストを書いても設計が改善しないのであれば､それはただの回帰テストであり､現状の追認でしかありません｡テスト駆動開発における質の向上の手段は､リファクタリングによる継続的でインクリメンタルな設計であり､｢単なるテストファースト｣と｢テスト駆動開発｣の違いはそこにあります｡...テストを書きながら開発することによって､設計が良い方向に変わり､コードが改善され続け､それによって自分自身が開発に前向きになること､それがテスト駆動開発の目指すゴールです｡(p307)
テスト駆動開発とは､ただ先にテストを書いて次にコードを書くということではなく､リファクタリングを絶えず可能にすることで､よりよい設計に洗練していくということなのだと感じた｡現時点の自分では設計についての知識が乏しいので､テスト駆動開発ではなく､ただのテストファーストになってしまう｡拡張しやすく変更に強いコードを書くために､設計を学ぶ必要があると感じていたので､設計を学ぶことの重要性について改めて認識できたことが大きい｡『デザインパターン入門』や『コードコンプリート』､『クリーンアーキテクチャ』を買ったので読むことにしよう｡設計を学んだあとで､またやると違った視点で見ることができるはず｡何回読み返しても新たな発見をすることができるスルメ本だと思う｡
訳者のt_wadaさんの話が聞けるので､おもしろいし参考になるのでおすすめです｡
