TDDの経験と現状のアンケート

「TDD(テスト駆動開発)ってどのくらい使われてるんですか？」と聞かれることがあります。それはですね、俺だって知りたいわー！というわけで、「TDDの経験と現状について」というアンケートを作りました。

10/23の段階で83件の回答がありました。ありがとうございます。TDD人気ありますね。中間報告として、これまでの回答を公開したいと思います。始めた時期と現在の状況のグラフです。

回答全体のサマリはこちらで見られます(回答したときに見られるのと同じです)。なお、こちらは随時更新されるので、本エントリの内容と一致しないかもしれません。
https://docs.google.com/forms/d/1pb29VBqO-kd10ks_x9oqvkMUy5rDW4nMoDnBPVM85yc/viewanalytics
※アンケートはまだまだ受付中です。こちらからどうぞ→ http://goo.gl/forms/fbWsZmH3El

分析してみる

2年以上やっている人が50%以上、最近始めた人は意外と少ない(1年以内が10％)という印象です。現状は、「よく使っている」は「以前ほどではない」も含めると約50%です。大雑把に言えば、長く使っている、使い続けている人が相当数いると言えそうです。(ただしアンケートに回答してくれた方が、業界全体(母集団)を偏りなく代表しているという根拠はないので、「いるね」という以上のことは言えませんけれど。)

今回このようなアンケートを採っているのは、TDD本当に使ってるの？意外と辞めちゃってたりしない？と思ったためです。TDDについて(特に今年は)議論がありますが、議論は議論として、現場はどうなのか。

もうひとつ、自分のことを振り返ると、以前ほどTDDしてないなあと思います。それは、コード書いてないから……ごめんなさいごめんなさい。でも書くときでも、やっぱり以前のような100%TDDはやってない。なぜだろうか。思いついた理由は2つです。

何でもかんでもTDDではなく、効果的に使うポイントがわかるようになった。
- 例: Webアプリはエンドツーエンドでテストするよね(Selenium Driverとか)
- 例: 静的データ構造はTDDあんまり意味ないよね
TDDは実は学習のツールだった。今は学習することが減った(コーディングについて)。
- 例: TDDのおかげでデザインパターンが使えるようになったが、今はTDDなくても使える
- 例: SQLAlchemyってどう使うんじゃ。TDDスタイルで実験してみよう。

他の人はどうだろう？特に2番の理由ってあり得るんだろうか？この検証が、アンケートのもう一つの狙いです。

期間と使用度合いの相関は？

TDDを始めてからの期間と、現在の使用度合いの関係を調べてみました。こちらが結果のグラフです。

注目したいのはオレンジと赤の部分です。「たまにしか使わない」「以前ほどではない」が、2〜5年のところで増えています(1年以内はデータ数が8件と少ないのでとりあえず無視)。5年以上では「現在もよく使う」が増えていますが、オレンジの「たまにしか使わない」も増えています(グラフだと見難いが、18%→24%→26%)。TDDの経験年数が長いと、「たまにしか使わない」人が増える傾向があるようです(わりと乱暴ですけど)。

さらに、理由も簡単に見てみました。「実装しなくなった」「今の仕事ではTDD困難」など環境要因を除くと、TDDを使う・使わない理由が少し見えてきます。2年以上の回答から、代表的なものをいくつか紹介します。

現在もよく使っているが、以前ほどではない
- 自明である事とそうでないものの区分けができるようになった。
- コーディングを進めていき、不安な箇所をTDDする等TDDとのつきあいかたが変わった。
- 言語スイッチが増え、他言語のユニットテストを調べなければ使えず、コストが高くなった。
- 最初は勉強や技能の向上を意図して、意識的にTDDを行うようにしていたため使用機会が多かった。現在はではTDDの得意な所、不得意な所がわかるようになり、使い所のみで使うようになっている。
- 教科書通りにやると疲れるから、最低限のテストコードで、最大限の効果を出すようになっただけ
現在はたまにしか使わない
- 概ね"TDD is Dead"に書かれている通りです。Railsで開発(略)という事情もあるかもしれませんが、以前ほどUnitTestをTestFirstで書くといったことはなくなりました。今は、(略)UnitTestを書くのは仕様が複雑なModelの処理の場合のみ(略) ただ、教育的な意味合いで、初めはしっかりUnitTestを書いてください、と指導することはあるので、スキルの土台としてのTDDは必要という認識です。
- TDDを用いたときの設計の勘所が自然と意識できるようになったこと
- 統合テストを重視するようになり、そちらにテストを書くというコストをかけるようになったため
- 全てをTDDのサイクルに乗せるとスケジュール的な無理が生じる場合が有る。
- ソフトウェアの寿命が短くなって頻繁に変更しない部分にまでテストを書くメリットがなくなったので抜き気味にやっている。
- TDDが有効な場ではTDDで開発しますし、そうでないなら別のアプローチを使います。適材適所。
現在はまったく使わない
- どんなクラスのI/Oにすれば良いか定まらないまま実装を始めてしまうため。区切りがよくなるまで(I/Oが定まるまで)xUnitは書いていない。
- いざ製造を始めると設計不備による仕様変更が多発するため、テストを先に作っておくと手戻りが多すぎる。
- モックの記述が非常に面倒。モジュール中のどのメソッドが何回目に呼ばれて何を返すとか、製造終了まで分かる訳がない。
- テストが動けばいいやというコーディングスタイルが蔓延し、バグが多発した。

(なお回答の生データのリンクを末尾に載せています。ここにない理由含め、全回答がそのまま見られます。)

また、理由をカテゴリに分類して分布を調べてみました。

理由	2〜5年前	5年以上前	計
環境	6 (75%)	2 (25%)	8 (100%)
適所	4 (40%)	6 (60%)	10 (100%)
棄却	1 (50%)	1 (50%)	2 (100%)
不明	6 (100%)	0 (0%)	6 (100%)

対象は、現状が「以前ほどは使わない」「たまにしか使わない」「まったく使わない」の回答です。表のパーセント表記は、横方向に加えると100%になるような計算です。分類は以下の定義で、主観で判断しました。

環境: TDDができない製品、職場環境である。実装をしなくなった。など
適所: いつ、どういうときにTDDをするか判断する(結果TDDしないこともある)。
棄却: TDDを理解した上で、現状では役に立たないと判断している。
不明: それ以外、分類できない、回答なし

以上、中間報告でした。アンケート自体はまだまだ回答を受け付けています。データが増えればまたお知らせしたいと思います。

※アンケートはまだまだ受付中です。まだの方はぜひどうぞ！→ http://goo.gl/forms/fbWsZmH3El

またTDDの現状について情報やコメントがあれば、教えてください。

https://facebook.com/yattom
https://twitter.com/hashtag/tdd
または本エントリに直接コメント

詳細なアンケート結果(閲覧のみ; 随時更新)
https://docs.google.com/spreadsheets/d/1jJX102o7i46WT1TF7TsQwcvAM4EHLNqOhlpBboTAikk/pubhtml?gid=1987591198&single=true
※今回の報告は、10/23までのぶんを対象に分析しました。