タワーズ・クエストの和田卓人さん (t-wada) のお話を聞いたのでメモメモ。 Kent Beck の TDD 本の翻訳本『テスト駆動開発』を書いてる人です。 和田さんによる追記もあるので、正確には翻訳＋αですね。
TDD の歴史は、バイブル的な本の出版歴を見ていくとわかりやすいみたいですね。
- 2002年: Kent Beck の TDD 本が出版される
- 2003年: TDD 本の翻訳『テスト駆動開発入門』がピアソンから出版される。しかし、ピアソンの技術部門の撤退で廃版となる
- 2017年: 和田氏によって TDD 本の再翻訳『テスト駆動開発』がオーム社から出版される
TDD は “Test Driven Development” ではなく、"Test-Driven Development" と書くのが正解みたいです（ハイフンがいる）。
xUnit Test Patterns by Gerard Meszaros
書籍 『xUnit Test Patterns』 では、2007 年の時点でテストコードのメンテナンス性の課題について言及しています。
- 重複の多いテストコードがあると、メンテナンスコストがどんどん上がっていく。
- プロダクトコードだけでなく、テストコードもメンテ対象であり、日常的なリファクタリングが必要であるという認識が必要。
- 「テストコードを追加するとメンテナンスコストが上がるので、テストコードはあまり追加したくない」という意見はそもそもテストコードに対する認識が間違っている。プロダクトコードと同じレベルのものと考えないといけない。
- だから、書籍のサブタイトルでも「Refactoring Test Code」と訴えている。
ちなみに和田さんは、こーゆー分厚い本はぶった切って持ち運びやすいサイズにして読むみたいですね。 私も本は読んで知識にしてナンボだと思ってますので、そのやり方には賛成です。 本には書き込みまくって自分の知識になったと思ったら捨てる。その繰り返し。
Mock オブジェクトについて
- Mock オブジェクトの登場により、Inside-Out な開発から、Outside-In な開発に変えられることが分かった。簡単に言うと、ユーザーに近い UI の部分から Mock を利用して作り始めるという考え方。Mock オブジェクトが、ただのユニットテストの道具ではなく、受け入れテストに近いところから開発するというプロセス改善のために使えるということが示された。 早い段階でリリースして、フィードバックを受けながら作り込んでいくというプロセスが現在ではよいとされている。
- 「動作するきれないコードはあらゆる意味で価値がある」by Kent Beck
- Mock 系のライブラリは強力になりすぎて弊害にもなっている。もともとは、テストを書いているときに「Mock に置き換えにくいので設計を改善しなきゃ」という設計改善の原動力となる部分があったのに、今は Mock ライブラリが強すぎて、汚い設計でも Mock を導入できてしまう。テストには「設計を改善する」という目的があるのに、これでは本末転倒だ。
TDD の T は「テスト」なの？
TDD の T は「テスト」の一部に過ぎない ─ 『Agile Testing: A Practical Guide for Testers and Agile Teams』
ある人が「テスト」と言ったときに、それが具体的に何を示しているかは、Brian Marick による4象限モデルによって分類できる。
UnitTest は、4象限のうち1つしかカバーしないので、UnitTest ができているからといって、「テスト」できているとは言えない。特に UnitTest には批判的な目で見るという視点が徹底的に欠けている（そーゆーところは、ユーザビリティテストとかセキュリティテストとかでカバーしなきゃいけない）。
TDD から BDD へ
- testdox/agiledox (2003) というツールで、テストコード（関数）から仕様書を生成できるようになった。
- JBehave (2003) → RSpec → Cucumber (2008) などいろいろ作られて、Cucumber では自然言語でテスト書けるようになった。
- ビヘイビア仕様の用語で考えることで、クラス名やメソッド名に捉われたテストを書かないように促される。
- BDD はもともとアジャイルプロセス的な位置付けになることを目指していたが、今はそのようには受け入れられていない。そんな大きな枠組みのものではない。
- TDD も、リーンスタートアップのようなより大きな枠組みの中て、リリースサイクルを短くするため1つの仕組みであると考えられるようになった。
- TDD は「スキル」です。写経することでスキルは向上できる。書籍 『テスト駆動開発』 では、写経して学びやすいように、Kent Beck の原著のコードを見直して、そのまま実行できるようにしている。
ユニットテストは品質を上げない
- テストは品質が「わかる」ようになるだけ。
- テストを書くだけでは品質は良くならない。品質を上げるのは、今も昔も「設計」と「プログラミング」であることに変わりはない。
- テストは再設計とリファクタリングを「支える」ものだ。
- テストを書いただけで設計を改善しようとしないのであれば、それはただ回帰テストしているだけで現状追認にしかならない。
その他、和田氏の意見
- TDD は自分自身が活用するためのツールとして使っていけばいいよ。「テストない＝悪」みたいに使われるのは嫌だ。テストを書いてからじゃないと絶対にプロダクトコード書いちゃダメとか、もともとはそんな意図はなかったはず。
- UI の自動テストには否定的。UI は変化してナンボのものなのに、テストが存在していることによって、変化させることに抵抗を持つようになってしまう。スナップショット・テスティングなどは、画面の変化に「気付く」ためのツールとしてだけ使うのがよい落としどころだと思う。そして、変化が明らかになったら、どちらが正しいかは人間がその時々で決めていくのがよい。
- コードの品質を見るひとつのやり方としては、「コードの重複率を時系列で見る」という方法がある。時系列で右肩下がりになっていれば、そのチームはよい活動ができている。Cyclomatic Complexity も時系列で見る。チームの Velocity も時系列で見る。だんだん生産性が下がっているのであれば悪い兆候だ。