テスト駆動型開発の落とし穴

いつもお読みいただきありがとうございます。感謝しています。

はてなブックマークの作り直しについて
で、テスト駆動型開発の落とし穴について興味深いことが書いてあります。

下記は、私の体験から、私のテスト駆動型開発に関する感想です。

自分は常々、テスト駆動開発とサービス開発は相性が悪いなと思っていました。新しい機能を作っているときや、新しいサービスを作っているときは、自分でも答えが見えていない状態で作っていることが多くあります。コードを書いているうちに少しずつ問題が解決されていって、最初は見えていなかったものが見えるようになり、答えがみえるようになる、ということが多々あります。作っては壊しを何度も繰り返すこともあります。

これは私が実体験していることから言えることなのですが、
これは実は、サービス開発と相性が悪いのではなく、自分が何を作ったらいいかがわからない状態ときに陥りやすいのです。

また、テスト駆動型開発に触れ始めだと、実コードとテストコードを分けて考えているため、どうしても、新規に開発するときに、テストコードの書き直しが、今までのコード作成のリズムとあわないため、自分のリズムで仕事ができていないと感じ、相性が悪いと思うのです。

テスト駆動開発では、細かい単位とは言え、ある程度事前に何を作るかを決めてテストを書きます。このプロセスが相性が悪かったのです。

こちらも、私の実体験からで同じことなのですが、何を作るかわからないのに、テストが書きようがありません。

また、テストだけではなく、実コードもどう書くかわからないでしょう。
テスト駆動型開発の問題ではありません。

では、どうするか。

まずは、何を作るかわからない場合には、テスト駆動型開発を用いないという方法です。

本末転倒に思うかもしれませんが、テスト駆動型開発になじめていない段階と何を作るかわからない状態の時には、まずは、何を作るのかというアウトラインをはっきり自分の中でつかうむほうがいいのです。

テスト駆動型開発も万能ではありません。

プロトタイプとわりきって、ある程度方向性を求めてから、今までのコードを捨てて、テスト駆動型開発をするほうが、工数がへるのです。

プロトタイプとわりきらず、そのまま実コードにして、品質が悪いというプロジェクトを、いままでどれだけ見てきたことか。^^;

テスト駆動型開発になれてくると、新規開発の内容（自分が何を作るかわからない、手探りな状態）のときでも、無くてはならなくなってきます。

・テストコードを実コードを同じであると思える状態になること

この状態になるとテスト駆動型開発が、自分の開発のリズムになるので、元の実コードだけの開発に戻れなくなります。


なぜ、戻れなくなるかは、
・自分のコードに自信がもてる
・結局は、テストコードがあると工数が少なくて済む事が経験的に理解している
・コードがシンプルになることが経験的に理解している
・テストを先に書くと、何をどう実装すれば良いかがわかることが経験的に理解している
からです。

その意味では、テストコードという概念ではなくなってくるのです。
ユーザーさんは使わないけど、実コードであるという概念になってくるのです。

ある程度のテスト駆動型開発の実践経験が必要となってくるのです。

恥ずかしながら、これまで自動化されたテストと呼べるテストがなかったため、ちょっと気を抜くとすぐエンバグしていました。今回の作り直しでテスト環境が整うので、だいぶ品質が上がるのではないかと思っています。

ここからも、テスト駆動型開発の実践経験が、十分でなかったのがわかります。

自分の開発のリズムが、実コードだけなのか、テストコード込みまでになっているかが重要で、開発内容が新規か、がちがちに決まっているかは関係ないのです。

繰り返す時に、実コードだけではなく、テストコードも捨てればいいのです。

そのときに、テストコードの作成が、重荷になっていると感じているから相性が悪いと思うのです。

上に書いたように、テストコードの作成が、工数を減らすと経験的に知っているからこそなのです。

私の経験からで、万人に同じわけではないでしょうが、テスト駆動型開発が染み付いている私としては、テスト駆動型開発が、ひとりでも同じ恩恵をうけれたら、嬉しいですね。