被らないようにタイトル考えるのも大変ですね。TDD Boot Camp 北陸に行ってまいりました。
書籍紹介ラッシュ
だいたい有名どころですが、あらためて。
- Emergent Design: The Evolutionary Nature of Professional Software Development (Net Objectives Lean-Agile Series)
- 創発的設計を為すピラミッド。ベースにあるのはコードの質。
- 達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 (Ascii software engineering series)
- 黒より白！アスキーから出ている方に上記の三本柱について書かれています
以下三冊は、現場で戦うあなたへ
- レガシーコード改善ガイド (Object Oriented SELECTION)
- テスト不在のコードと戦うための良き友
- データベース・リファクタリング
- 本番データがすでに入ってしまっているデータベースと戦うための（ｒｙ
- xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
- テストケースが増えてきて、テストのリファクタリングが必要となったときの（ｒｙ
ペアプロのデモ - FizzBuzz
id:t-wada を t、id:katzchang を k と略しています。
- t「3の倍数を渡すとFizzと返す」
- k「3がエラーになってる」
- t「漢数字にしよう」
- k「クラス名何にしよう……」
- t「それじゃだめ。まずは assertEquals を書く。assertEquals("Fizz", actual)」
- k「じゃぁ、assertEquals("Fizz", fizzbuzz(3)) で」
- t「fizzbuzz メソッドを Eclipse で自動生成」
- k「もっとも簡単なコードでテストを通す。 return "Fizz";」
- t「なんでこんなことをするのかというと、テストのテスト。仮実装をバカにしてはいけない。テストを足していいのは green のときだけ」
- k「次のテストメソッド名は、"_1を返すと1と返す"」
- t「あ、アンスコつけるんだ」
- k「わりとよくやります」
- t「はい red になった。これが三角測量。ここから仮実装するか、一気に解くかは個人個人のスキル」
- k「じゃぁ一発で実装。よし、green」
- t「まずテストの名前を決める。assertを書く。メソッド名についてはもめてください。次はテストを書く。仮実装かどうかはペアに任せる。仮実装だったばあい、それを打ち破るテストを書く。」
Python で TDD ペアプロ
ペアプロのお時間には、Python チームにまぎれてました。unittest モジュールと、doctest でのテスト。プロダクションコードのコメントとして書きつつも、しっかりとテストとして機能する doctest は素敵ですね。Java でもアノテーション駆使してこんなこと……はさすがに難しいか。そもそもバイナリサイズが膨れてしまいそうで微妙です。
ペアプロなので、書きながら「この関数の仕様はどうする？」という話になるわけですが、例外処理の扱いをどうするかがだいぶチームによって異なりました。結果的に @hikaruworld チームでは、引数に想定外の型が入ってきたら明示的に raise ValueError、@yuuitiro チームでは、そういった型チェックはしない、という方向性になっていました。
せっかく LL らしく、本質的な部分を数行で書けてるのに、型チェックの部分のコードが長くてかっこわるいーという話を @hikaruworld としていたところ、@cafistar から「それデコレータできれいにかけるよ」というアドバイスをもらい、きれいに書き直すことができました。こんな感じで夜は更けていく……
