レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

10章プラクティス6まずテストを書く

テスト駆動開発は死んでいないのか？

本章で説明するテスト駆動開発（TDD）はもう死んでしまったと主張する人たちもいる。良いアイデアに見えるものの実際にはうまくいっていないと言うのだ。多くのテストや実装に依存するテストがかえって負担になってしまうという「テストによるダメージ」について語っている。

実際のところ、この指摘はそのとおりだ。

開発者がいつテストを書くのをやめるべきかわからないときに、「テストによるダメージ」が発生する。

開発者がテストファースト開発を行う利点は、既存のコードを変更するときにサポートを得られることだ。しかし、あまりにも多くのテストを書いたり実装依存のテストを書いたりすると、テストの変更が難しくなる。こういったテストは変更しやすさの手助けになるどころか負担となり、コードの変更は困難になり時間がかかるようになる。

かつて、退屈するまでテストを書くようにテスト駆動開発の熟練者に言われたことがある。退屈した時点で、おそらくそれ以上のテストを必要としないというのだ。この方法の問題は退屈するまでのしきい値が人によって異なる点にある。「退屈するまで」とは、どれくらいのテストを書けばよいのだろうか。

テストは仕様であり、ふるまいを定義するものだ。

テストをこのように捉えるとテストの適切な数と種類が明らかになる。コードを安全に変更するための最適なテストが提供されるだけではなく、実装にも集中できる。これなら作業が終わり次第、次のタスクに進める。

ほかの複雑なものと同じように、正しい方法は数少ないが間違った方法はごまんとある。テスト駆動開発を正しく適用できなかったからといって批判しないでほしい。

テスト駆動開発を利用して開発を進めることを私は提唱している。そこで、いつも伝えている ...