TDDBC札幌2.0に参加してきました

1.5に引き続き、TDDBC札幌2.0にも参加してきました！

今回は@shuji_w6eさん、@t_wadaさんの豪華2名の講演に加え、サポートメンバーの方々の楽しくてためになる自己紹介もあり、午前中の座学も盛りだくさんでした。

講演の中で心に残ったこと

TDDについて

「テスト」という言葉の混乱
テストを「誰がなんの為に」で再分類する
- DeveloperTesting, CustomerTesting, QATesting
- TDDで言うテストとは、DeveloperTestingのことをさす
- 最近はCustomerTestingのほうまでテスト自動化の範囲が広がっているらしい
現代ソフトウェア開発の三本柱
- ある意味テスティングよりもバージョン管理のほうが大事。命綱。
三本柱とは三脚椅子。一本でもなくなればプロジェクトは転倒する
テストコードもメンテナンスするため、コピペではいけない。良い名前。重複排除
TDDと黄金の回転
- 「汚い」から「きれい」に突破できるのはRefactoringしかない。ここが大事
  - それを支えるために、リファクタリングが失敗したらRedになる仕組みとバージョン管理がある
テストは目的ではなく手段
- 最大の理由は心理的なもの
TDDの真の目的は、健康
- 変化に対応できるのは健康体のコードだけ。贅肉だらけの体では対応できない
- 変化に対応できるのは健康体のチームだけ。疲弊し切ったチームではない

TDDとレガシーコードの改善

テストできる地点を探す継ぎ目(Seam)
何が正しいか vs. どう動いているか仕様化テスト
- バグフィックスと同時にやらない
コンパイラを味方につける
テストするために手段は選ばない
カプセル化よりも、テストが大事

デモで気づいたこと

一つのテストケースの中で、下の方から書く（assertから）
スタート地点は、最終的なAPIを最初に決めて、それから細かいところ

@t_wadaさんの〆の言葉

"acts as professional" プロフェッショナルならば、自分の書いたコードにテストを書く
技術書の「写経」の方法
TDDはスキルです

チームでのTDD実践

作業の流れ

作り直しではなく、レガシーコード改善コースを選んだ
まずは肩ならしに簡単なクラスから仕様化テストを書いた
つぎに濃そうなクラスの仕様化テスト
仕様化テストだけで終わってしまうのは嫌だったので、先に改善したい点をリストアップしておいて、残り１時間半くらいになったら仕様化テストを切り上げた
些細な改善だが、とりあえず１つ改善してみた

実践内容の個人的な振り返り

ほかのチームの発表を聞くと、設計的な議論を結構突っ込んでやって、それの改善を行っているチームもわりとあった。私のチームでは濃そうなところは程よくすっとばして、全体的にやりきることを重きにおいて作業した。チームの４人うち二人はTDDが初めてだったし、私を含む３人はあんまりJavaは詳しくないという状況だったので、これぐらいでちょうどよかったんだと思う。

@shuji_w6eさんがおっしゃっていたような、テストがしにくいところは継ぎ目を探して多少無理にでも切り出してみる（かなり表現違うはずけど……そんな感じのこと）、というのはやらなかったというか、やっていてもそれが必要な箇所に気がつかなかったので、まだまだ習得できなかったことがたくさんあるということですね。それは素直に自分のスキル不足を認めて、また次の機会に学ぼう。TDDは習得可能なスキルだから、いつかできるようになるはず！

全体を通しての感想

@t_wadaさんの"acts as professional"という言葉に感極まりました。この言葉、ずっと心に留めておきたい
@shuji_w6eさんをはじめ、サポートしてくれた皆様、毎回本当にありがとうございます
ペアプログラミング楽しい。疲れるけどほんと楽しい
集まっている人たちは本当にすごいひとたちばかり。そこに参加できるって感激
懇親会、めちゃ楽しかったです！
グリーンバンド、すごく欲しかった……

hachiNote

勉強したことをメモします。