2011年08月01日

TDD Boot Camp 東京 1.6 に参加してきたよ


詳細は、Togetterとかあるから、見ればいいと思うので、

ここでは、わたしなりの感想というか、意見というか、考え方というか、そういうものを書いておきたい。

読みにくいのはいつものことなので気にしない方向で。



前書き



わたしは、正直、プログラムは素人、っていうか全然コードを評価してもらったことがないレベル。

でも、書きたいものはだいたいすらすら書ける。

書いてる間に、動かさなくても、ある程度のバグは、「あっ」と気づくこともできる。



そうすると、「テストコードなんて必要ないんじゃないの」って思うんだよね。

でも、必要だと言うことがわかってる自分もいるの。

リリース後の変更とかの『命綱』っていわれている部分がそれ。

そんな、必要そうな、必要なさそうな、不安定な気持ちをどうにかしたくて参加したってわけ。




んで、いくつかの観点というか、ごーるに向けてまとめていきたいんだけど、

用語とかはわたしが勝手に頭の中で想像した内容を指しているので、

意味わからなかったらスルーするのが良いと思うよ。




下に書いた順番で進めていくよ。

見てわかるとおり、この記事の目的は、

TDDの本質を知り、広める方法を考えるってことだよ。

と、偉そうに書いてみる。




・TDDでのテストコードは誰のためのもの?

・TDDでのテストコードは何のためのもの?

・テストコードはどの程度書けばいいのか

・テストコードは最初に書かなければならないのか

・TDDと品質保証の関係

・TDDを広めるために



TDDでのテストコードは誰のためのもの?



さぁ、さくさくいこう。長くなっちゃうからね。

Togetterを見ていると出てくるけど、

正統派TDDと検証指向TDDって言うのがあるみたい。

この記事でTDDっていったら正統派TDDの方ってことで。

それは、つまり、テストコードはプロダクトコードを書いている人(開発者)のためのものってこと。



TDDでのテストコードは何のためのもの?



テストコードは開発者が「不安」な部分を書いていくの。

これによって、『安心なコード』の『作成を促進する』ってこと。



ここで注意したいのは、『品質が保証される訳ではない』と言うこと。

でも、『保証はされないけどバグは減る(品質は上がる)』んだよね。

そりゃ、開発者が不安に思うところを検証するんだから当然の結果だよね。



テストコードはどの程度書けばいいのか



TDDでは、不安をテストコードにしようって言ってたよ。

ここでも注意、書き始めるとよくやっちゃうのが『仕様をテストコードにする』こと。

これは、違う。もちろん、やっちゃダメという訳じゃないよ。

ただ、その仕様はほんとに不安に思ってるの?っていうこと。

不安に思っていないなら、ただ、メンテナンスが必要なコードを増やしているだけだからね。

あ、そうそう。不安に思ってないからって、
テストコード書かないでいて、あとで不具合いっぱい出たら、

きっと、自意識過剰ってことだよ(笑)



TDDと品質保証の関係



前にも書いているけど、TDDは品質を保証するものではないんだよね。

「じゃぁ、やらなくても良いの?」という質問には、わたしなら「Yes」と答える。

「やった方が良いの?」という質問には、わたしなら「わからない」と答える。


書くかどうかは、その人のスキルとプロダクトによると思うな。

「簡単」、「難しい」、「作ったら放置」、「作っても長くメンテナンスを続けてバージョンアップする」……。

そんな状況によると思うの。


何度でも書くけど、TDDは品質を保証するものではないの。

品質を保証するのは、別の段階(フェーズ?)でやっているでしょ。

やっていないという場合は、「別に今までもやってないんでしょ」ってことで。


あくまでも、TDDは開発の促進のためにあって、

その結果、変更時にチェック機能を果たす『命綱』が『副産物』として誕生してくるに過ぎない。

その『命綱』も、当然、品質は保証しない。決して、保証しない。無駄ではないけど保証しない。

なので、『TDDのこころ』に、『テストが命綱』って言うのがあったと思ったけど、

わたしは、これは、『TDDのこころ』ではないと思う。


この命綱は、当然、開発者によって太さ(量)とか強度(質)が変わってくる。

決して、万能のツールじゃない。でも、安心はくれるし、助かる確率も高くなる。



TDDを広めるために



2011/07/31のTDDBCでは、Togetterにも書いたけど、

結局、『周囲(主に上)に広めて通す方法まではわからなかった』。

だけど、その後、いろいろ考えてたら、なんか自分は勘違いしているのではないかと思ってきたの。



「偉い人がテストに期待するは、品質の保証である。」

……この通りだったら、TDDの導入は無理に見えるんだよね。

だって、TDDは、品質を保証するものではないから。

バグの数が減る?そうそれは、確かに数値は出ている。

でも、それって保証された数値でも何でもないしね。



そこでもう一歩立ち戻ってみるよ。

TDDは誰が何のためにやるのか。

『開発者』が『安心なコード』の『作成を促進する』ため。

『命綱』は『副産物』。



つまり、「できたテストコード自体が重要だと思うこと」

「テストコードがプロダクトだと思っていること」が間違いじゃないのかと思うの。

もちろん、そうなるかもしれない。でも、そうである必然性はないんじゃないのかな、TDDには。



そう、「テストコードは破棄したって良いと思う」んだ。

言ってれば、ちょっと、紙にメモしたようなものだと思うの。

メモした内容を、電子媒体にして資料として保管するか、ゴミ箱にポイするかは自由でしょ。

メモを禁止されていない限り、TDDもまた禁止されていない。

上に許可なんて求める必要はないんじゃないかな。



あとは、周りに広めるだけ。それこそ『メモしなよ。』と同じ要領だと思うの。

なんか実はすごく簡単じゃない?



重要なことは、TDDは必須ではなく品質を保証しないと言うこと。

そして、それはとても自由だと言うこと。



長くなったけど、何かの気づきになると良いな。

最後まで読んでくれてありがとね。

タグ:TDD
posted by そら at 22:12| Comment(9) | TrackBack(0) | 日記