はじめに
TDD（テスト駆動開発）をワンマンプロジェクトで実践してみました。いまさらと思われるかもしれませんが、実際の現場は意外と保守的なものです。自分の周りではバージョン管理システム（Version Control System）でさえ、使っている人が少数派という有様です。
しかし周りが保守的であることは自分がやらないことの理由にはなりません。やってみて、不都合があればそれを「自分のやらない理由」として記録しておけば良いだけです。
結論
是非やるべきです。
しかしまだ「やりたくない」と思っている人へ...。
初期コストは大きい
まずは正直に、初期コストはとても大きいと正直にいわざるを得ません。
概ね以下の３つのコストがあります。
- 導入コスト
- 学習コスト
- 保守コスト
導入コスト
TDD を行うには複数のツールが必要になる場合が多いです。すべてのツールを導入できたとして、不具合が起きたときに自分のテストコードがまずいのか、いずれかのツールがまずいのか、判断に困る＿＿一言で言うと「はまる」＿＿可能性が多々あります。しかしたいていの場合はネット上に情報があるものです。
学習コスト
ツールの使い方について、学ぶ必要があります。もしプロジェクトに余裕がない場合は「割に合わない」コストになるかもしれません。しかしやがて身に付いていけば、将来のプロジェクトからは、それほど気にしなくて良くなるかもしれません。
保守コスト
これは「初期コスト」ではないと感じられるかもしれませんが、TDD を導入して最初のプロジェクトの場合は、それより後のプロジェクトに比べてどうしても大きくなります。ですので、最初のプロジェクトの保守コストは初期コストとして考えたほうが良いです。
初期コストは回収できるのか
一つのプロジェクトでは回収できないでしょう。
理想を言えば、メンバーが各々、業務外で学習をしてから導入するというのが望ましいです。しかしそのように意識があり、実力をもちあわせているチームならとっくに導入されているでしょう。また練習でやることと実践でやることには、どうしても大きな隔たりがあります。各々が独学すると、後になって定石を統一するコストなど別途がかかる可能性もあります。学習曲線も個人差があります。
テストファーストが意味分かんない
テストファーストは TDD の目指すべき理想郷です。つまり、最初からそこに行かなくて良いです。というか無理でしょう。しかし TDD を調べるといきなりそこからはじめているサイトが多いです。やってみてわかりましたが、最初からそれは無理ってもんです。テストアフターから始めて、徐々に慣れていけばいい。
テストファーストでなければ TDD ではなく、単にテストの自動化を導入したに過ぎないといわれるかもしれません。しかしそこを通過しなければ TDD にたどり着くことも、TDD の世界に足を踏み入れることもできません。千里の道も一歩からです。
最初の一歩のその先に
初期コストを乗り越えて導入し、その甲斐はあったと感じます。
- レベルアップ
- 品質アップ
- モチベーションアップ
レベルアップ
TDD 導入に腰が重い人は、自分の実力にかなり自信があるのではないでしょうか。「TDD を導入しなくても仕様を満たしたコードは書けているのだし」と思っていないでしょうか。私はそんな自惚れ屋だったのだと思います。
しかしやる前と後では、もう別世界です。確実にレベルアップします（もちろん自分はまだまだ不十分ですが）。TDD を導入せずに仕事をしていた場合より何倍も短い期間でレベルアップできます。
品質アップ
これはもう当然です。コードをコミットする前に、かなりテストができますし潜在的な不具合も駆逐できます。
コードカバレッジは「100%（完全）を目指さなくてもいい」と多くの書にありますが、最初は是非目指してください。「こんなところ、どうやってテストすればいいんだろう」「レアすぎるルートだから目をつぶろう」と思うようなところを「どうすればテストできるか」とアタマをひねることは（楽しいし）とにかく自分のスキルアップに貢献します。
モチベーションアップ
これは予期せぬ良い効果でした。
初期コストの大きさに、初めのころはやっぱり気持ちが重たかったです。しかしコードの品質と自分のスキルが同時に早く上がっていく。それは何にも替えがたい喜びであると、多くの（自分と同じ）エンジニアの方に同意していただけるものと思います。
まとめ
- 初期コストは大きいです。しかし見返りも大きいです。
- 自分のレベルアップが加速します。
- モチベーションも飛躍的に大きくなります。
- 最初はカバレッジ 100% を目指すことで、より多くのスキルが身に付きます。
参考書籍
↓読んでませんが...。
