@kotyのブログ

PythonとかAWSとか勉強会のこととかを、田舎者SEがつづります。記事のライセンスは"CC BY"でお願いします。

TDD Boot Camp Nagoya に行ってきた

↓こちらに行ってきました。
http://kokucheese.com/event/index/2467/

和田さん、@bleisさん、ほか主催者のみなさん、お疲れさまでした。セミナーやカンファレンスの現場に行くのはやはり楽しいです。以下日本語でおkですみませんが、メモ的なものを。。。

Javac/c++、.NETが大半かと思いきや、集団に偏りがあった。名古屋は関数型言語が盛んなよーだ。ocamlなんて初めて耳にしたよ。

1日目午前

TDDエヴァンジェリスト(?)和田卓人氏のTDD入門。

  • 仮実装でテストのテストをする。これに失敗するならテストにバグがある。
  • その後三角測量用のテストコードでREDに
  • その後プロダクションコードを修正してGREEN
  • 不安をテストにする
  • 真の目的=健康
  • 一番の近道は「遠回りだった」

所感

「TDDの真の目的は健康です」っていうのはプログラマ始め現場の人間にとっては納得できるところだけど、えらい人にそんなこと言ったって「おめーらが楽するだけじゃないか。仕事ってのは厳しいもんなんだ!昔はな(以下略」って言われるのが関の山。部として、プロジェクトとして、会社としてTDDやるためにはトータルとしてコストを下げられるよっていうのをアピールしてくしかないんだろうな。

和田さんが話の中で「仕事でペアプロやってるひといますか?」という質問に対して、手はあがらなかった。これが実際ってことか。

1日目午後

TDDペアプロ体験。
VBで希望していたが人数が少ないためC#にしてと事前に言われていた。だけどたまたまVB希望者が見つかりVBにて作成。ペアプロはちょっと気をつかってしまった。後輩にOJT的に教えることはあっても、力が同じ人どうしでプログラミングすることなんてないもんな。このへんは慣れかなぁ。

DateTimeをラップしてシステム日付に依存しないようにテストを書くっていう、業務アプリにありがちな課題でした。#If TEST という条件付きコンパイルと、Interfaceで本物と偽物を切り替えるという二通りの実装があった。

懇親会

金融系のシステムの保守をやってるって人と話しけど、やはりお互い悩みは同じ。レガシーコードとの戦いです。。。

2日目午前

レガシーコード改善ガイドを元ネタに和田さんのお話と、参加者から提供のあったレガシーコードをテストで保護していくライブ。

データと戦う
テストコード量との戦い
  • FragileTests・・・プロダクションコードをちょと直すだけでREDがたくさん出ちゃうテストコード
  • 大量のテストコードが足を引っ張る→テストをリファクタリングする。余計なテストを省く。今のところこれといったKnow-Howなし
  • Mockを作るとMockのメンテが必要になる。テストの独立性とトレードオフ

テストが無い状態からすりゃ、贅沢な悩みっすね。

レガシーコード改善

 テストできる地点(Seam 継ぎ目)を探す、作る

何が正しいか<<どう動いているか
 →仕様化テスト
  現状を正としてテストに記録していく。
  actualをexpectedに記入
カプセル化<<テスト容易性
 →テストをするためには手段を選ばない

所感

仕様化テストが作れればもう勝ったようなもんですねー。
サンプルとなったレガシーコードは外部の依存がなくて比較的簡単な方な印象なんだけど、それでもあれだけ苦戦してしまうのだからやはりレガシーコードの戦いは辛く険しいもんです。

@bleisさんのテストメソッド名のつけ方は参考になった。○○のとき_△△が返る。

2日目午後

winformの中に書かれた業務ロジックの分離。
こればっかりは命綱なしでやるしかない。ペアプロ必須。できれば3人以上。

  1. 中間変数を介するように変更
  2. クラスに出す
  3. テスト可能になったら、仕様化テストを書く

InternalVisibleTo属性なんてあるんすね。だがしかしPrivateVisibleTo属性はない。

所感

プロダクションコードを直したい衝動を抑えて少しづつ進む。どうしてもイキオイで大工事をしてしまいがちだが、壊したときに手に負えなくなってロールバックするはめになる。この辺も慣れなんでしょう。

仕様化テストを書くところまでがレガシーコードとの戦いのキモで、それさえできちゃえばもうフリーダムといっても過言ではない。ところが、いわゆる「継ぎ目」が存在せず仕様化テストのための「継ぎ目」を作り出すための修正が必要ことが多い。だけどそんな修正する勇気がないっていうのが現実です。そこをどーすんだろー??っていう疑問を解決したいってのが今回のTDD Boot Campの自分にとっての目玉だった。

こればっかりは保障するものがないんで、「気を付けてやる」しかない。複数人でやるしかないってことだなー。と身に染みてわかりました。


ここまで読んでいただきありがとうございます。ちょびっと遠方でしたけど、勉強になりました。はてダを書いて満足せずに仕事にフィードバックしたいです。