TDDで開発効率が上がらないと感じた3つの理由

結論

TDDを学んで、サンプルコードを実装してみた。
TDDは自分の開発スタイルにあっておらず、TDDによって開発効率が上がらないと感じた
TDDが目指している効能は、テストを初めに書かなくても実現できるのでTDDを自分の開発スタイルに取り入れないことにした

記事の背景

最近、テスト駆動開発を読んでTDDについて勉強しました。

自分の開発効率や設計スキルの向上に活かせないかなと期待していたのですが、この記事で解説する理由で、自分には合わないなと感じました。

※ TDD自体や、それを使っている人を批判する意図はないです。

TDDが目指しているもの

TDD再考 (3) – TDDが解決しようとした問題は何か？ – ゆびてく

TDDが目指しているものはこちらの記事にまとまっていますが、より少なくまとめるとすると、テストを先に書くことで

テスタブルな、いい設計のコードを書く
小さなステップで進むことで、開発時の心理的余裕を確保したり、開発生産性を向上させる

ことが重要な部分かと思います。

TDDは開発効率を上げないと思った理由

自分の開発スタイルの中で、TDDが目指すメリットを本当に享受することができるのかを検証するために本に書かれていたサンプル問題をGolangで実装しながら試してみました。

しかし結果としては、TDDの手法は自分には合わないということがわかりました。

理由1: テストの修正が頻繁に発生するから

設計を考えながら実装する場合、実装途中でいい設計に気づき何度も実装を修正する必要があります。TDDで開発している場合、実装が変更されるとテストコードも修正する必要が発生するので、修正コストが余計にかかってしまうと感じました。

確かにテストを先に書くことでテスタビリティが担保され、良い設計になりやすいとは思いましたが、テスタビリティ以外の理由で実装を途中変更する必要に迫られ、修正をすることが頻繁にあることに気づきました。そのような修正が発生するたびに、少ないながらもテストコードの修正が必要になることが自分にとってはストレスになっていました。

理由2: 重要でないテストが量産されるから

TDDで開発する場合、より網羅的にテストを書くことになります。しかし一方で、バグが入る可能性がほとんどない関数などに対してもテストを書くことになり、重要でない部分に対するテストが多くなってしまう傾向にあると思いました。

テストを最後に書くようにすると、重要でない部分のテストはスキップしたり、他のテストによってテスト範囲が重なることで担保されていたりするので、テストのボリュームが少なくなります。これによってテストファイルが小さくなり、メンテナンスコストも下がると感じました。

理由3: 小さなステップで進むことはテストを使わなくてもできるから

TDDでは小さいステップを踏むことで

過剰な設計
進捗が生まれやすいため心理的余裕ができる

ことが良いなと思っていました。

しかし小さいステップを踏むことは別にテストを書かなくてもできます。

僕の場合は、

フローチャート
クラス図
コメントだけで処理の流れを書く

などして、小さいステップを踏みながら全体を設計してから実装に入るようにしています。

このようにTDDでテストをわざわざ書かなくても同じようなメリットを享受できるため、わざわざTDDを使う必要はないなと感じるようになりました。