Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。

テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！

で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。

で、早速なんだけど上記ブログから引用させてもらうと

まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。

id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだらけなテストで品質管理とか何言ってんの状態。

で、じゃあテストってどうなのよって話になると思うので、俺が気をつけてることとか考えていることを書いていく。

俺は TDD が結構好きなので、基本はテスト書いてからコードを書く。 でも、これは品質管理のために書いてるんじゃ無くて実際にサーバ立ち上げて何回かクリックしたりして目で確認するのがめんどくさいとか、コンソールに表示された長い文字が正しいかどうか判断するのがめんどくさいから緑か赤で判別してるだけって感じ。

id:t-wada がよく言っているデベロップメントテストってやつ（だと思う）

んで、ここから話がややこしくなってる原因だと思うんだけど、こういう開発を進めるためのテストで品質管理をしようとしはじめるんだよね。 で、それは別にそんなに悪い事じゃないんだけど本質的には違うものだと意識しておかないといけない。 意識しないで書くとデベロップメントテストで品質保証しようとして無駄に多いテスト書いて「テストが負債になってコード書きにくい」とか上記のブログにも書かれてる「地獄への道は善意で舗装されている」的な馬鹿なことが発生する。

でもこれ、考えるとすっげー当たり前の事なんだよね。 だって、 デベロップメントテストは開発者がアクセルを踏むためのテストで、品質管理のテストは開発者に適切にブレーキを踏ませるためのテスト なんだから。本質的には逆を向いてるんだよね。

それを意識しないから「とりあえずテスト書いておけば人に指摘されなくて済む的なチンケなプライド」とか、「昔テスト書かなかった自分への贖罪」とか、「チャンとテスト書いてる俺カッケー」とかのドロドロしたものが混じって負債に近いテストしか書かなくなっちゃうんじゃないかな。

でも、デベロップメントテストってその性質上、実装ベッタリになっちゃう事が多いと思うんだよね。だって開発を進めるために書いてるんだからなるべく小さくサイクルを回したいしそれはしょうがないと思うし、別に悪いことじゃ無いと思うんだよ。

ただ、それ、もしくはそれだけを品質管理の為のテストにしちゃうのがややこしくなってるんだよね。 でも、ぶっちゃけ Web 開発に置いては有る程度許容しちゃっていいと思うんだよ。それこそ組み込み系のような一度製品出しちゃったら回収騒ぎで数億円が一気にぶっとぶとかじゃない場合がほとんどだから（そういうのと比べれば）最低限に見える保証で出しちゃってエラーが出たら直せばいい。 同じ理屈で、課金系とか認証系の部分は開発者に適切にブレーキを踏ませるべきなのでテストを充実させておかなきゃいけない。

なので、それ以外の本当に大事なところ以外はデベロップメントテストを流用してある程度品質を担保しつつ、短いサイクルでリリースを繰り返して大きな障害を出さないようにするのがいいんじゃないかな？

で、テストを書くときは、 アクセルを踏むためのデベロップメントテスト なのか 適切にブレーキを踏むための品質保証のためのテスト なのかを意識するだけでだいぶ違うんじゃないかな。