うさぎ組

kyon_mm with software

このエントリーをはてなブックマークに追加

「テスト書きすぎ問題」に関して思うこと

事の発端

http://hitode909.hatenablog.com/entry/2013/10/14/094604

上記のブログに対するTwitterやはてなブックマーク上でのコメントが10/14から10/15にかけて多数流れていました。内容を読んだときはまぁそうだよなーって思うことがありつつ、よく書いたなって感じだったんですけど、コメントのほうがいろいろとひどい内容が含まれていたので、自分の考えも含めてまとめておこうかと。

要約

自動テストをどれくらい書くかはプロジェクトにおけるリソース(どんなスキルの人)の割り当て方次第だと思っていて、おそらくhitode909さんの記事書かれていないこともたくさんあって、hitode909さんの方針もDHHさんの方針も正解であるときもあるって感じ。

あと自動テストの話がよくでるけど、そもそも君たちは何(どんな品質)を保障すべきか考えた上での振る舞いをしているのかっていう。

hitode909さんが理想とする開発ではどうであるべきなのかっていうのをちょっと知りかったですね。

それぞれの意見について

まず、ここで想定されている現場を持っている人たちは少なくとも2人いて、DHHとhitode909さんです。それとコメントをしたたくさんの人たち。

少なくともhitode909さんの周りは「プログラマーにおける当たり前品質を満たす程度のテスト」を書いてくれる人がそんなにいない。ということだと思います。 つまりはリファレンステストですら不足している。。。自動テストを周辺にひろめつつ、自身の生産性を落とさないための一種の強い教示として記事中にあるくらいの自動テストへの取り組み方をしているのではないでしょうか。 naoya_itoさんからもコメントがあるように長期間保守していくものがある中でテストを書いてくれる人がいないというのは、とても辛いでしょうし、その中では強い意思でテストをしていくのは納得できます。もちろんいろんな接し方をご本人ではされているのでしょうけど。 ただ気になったのは、hitode909さんの書きっぷりから見ると「ある程度自分にとって都合のいいテストしか書かれていない」という状況なのかなぁと思いました。バグっているテストコードばっかりになったらどうするのかという視点を聞いてみたいですね。(GREENになっているけど、実はちゃんと検査されていないだけだった。とか。)

対して、DHHさんは開発者としてテストとの付き合い方としての原則論を語っているわけですよね。作業時間とかテストコードの割合とか、テスト対象についてとか、テストファーストの取り組み方とか。 多分、DHHさんの中では「こうできるチームであろうとしよう」みたいなことを言っていて、DHHさんが毎回できているかはもうちょっとブログ読まないとわからないです。 Cucumberはプログラマ以外が使うべきっていうのは僕も大賛成で、Scenario BDD系のFeaturelは基本的にスプリントバックログにあるバックログアイテムと大して違いがないわけで、というか、その単位くらいで使うのが妥当だとおもう。(というのはなんどか話してきた。)

コメントを読んでみると、

テストを書かなすぎて炎上になるより、テストを書きすぎているくらいのほうがマシ。という意見がちらほらあって、ただ僕はテストありすぎて炎上とか見たことあるので、どっちもどっちですね。テストが通らなくなった時に、理由がわからないとリリースしていいのかの判断追求にものすごい時間がかかったり。(改修したら、別のコードがエラーをはいていて、その別のコードがスパゲッティになっていて理由がわからない的なイメージ)あと数万件のテストとかと戦っている人たちの前で同じ事を言えるのかなぁ感はあります。 あと意味のないテスト(境界値でもないパラメータを選んでいるのに、重複しているようなテスト)もたくさん見てきたので、それでどんなバグが出るのかわからないもののために気をつけるのがつらいですね。

テストは自信がないからするとか正しくなんですけど、こうもたくさん「なんの自信、どんな不安」かわからないものを書かれていると、「不明瞭な自信とか不安のためにテストするくらいならドブに捨てて、達成したい品質考えなおせば?」「不安だからテストすると不安だからダブルチェックするとどう違うの?」とか悪態づきたくなりますね。

テスト書かなすぎて問題になることももちろん僕も経験しているので、「書きすぎるより書かなすぎるほうがいい」なんて思っていないです。 どちらかといえば、例えば「C0は70%にしたいですよね」とか「ストーリーに対するハッピーパスが通ることくらいは確認してから結合テストに回したいですね」とか具体的に何ができたらって合意をとりたいなっていう感じです。 hitode909さんやkazuhoさんも言っているけど、こういった話において形容詞使ってたら問題は解決しない。

あんまり関係ないけど言いたいこと

ずっと言おうと思っていたのでここで書こうと思うのですが、「自動テストを書きすぎるのが問題なら、最小限のドキュメントで済むような手動テストを設計してやってみる。」っていう発想というか、議論がほとんどないんですよね。 非難しているわけじゃなくって、単なる感想なんですけど、手段に囚われている感があって、何を保証するためのテストなのかわからないなー。この人たちはコードを常に書きやすくしたいくらいの感覚なのかなぁ。って思うんですよね。 別にそんなことない人がたくさんいるのは知っているんだけど。

テストコードを書きすぎないようにして、余ったリソースは「人によるテスト」「テストと開発の視座から考えるテストをしなくてもいい設計」とかに費やしていくのがやっぱりいいと思っていて、原則は後者の「テストしなくてもいい設計」をいかに増やすかであると思うんですね。

「自動テスト」と「手動テスト」の保守コストというのは異なった性質をもっているので一概に「どっちに重きを置くのが正義だ!」とは言えないわけです。その道の玄人みたいな人に手動テストしてもらったほうがたくさんバグが見つかるとかありますからね。

で、どれくらいなのか

テスト戦略(対象とする品質、対象とするテスト対象、因子水準の大まかな選定、網羅対象、網羅基準、優先順位、見積り、やり方、時期)を考えて見ることから始めましょう。そしてそれが必要ない場合もあるので、そのときは必要ないなりのテストになるのではないでしょうか。

件のhitode909さんの話はホワイトボックステストによって多くの品質を確保しようとする試みですが、それが全体として有効なテスト戦略であるかどうかはプロジェクトにテストに詳しい方が入ってみないと(そしておそらくはhitode909さんが一番近いのかもしれない)わからないのではないでしょうか。

最後に

他にもいろいろ書いていたのですが、あんまり話がつながらなかったので、消しました。消した部分について聞きたい方は僕を飲み会にでも招待してください。

書きながらですが、見積もり可能なテストというのをもっと考えたり、啓蒙していきたいと思いました。  うさみみより。