自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である

本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO

[megascus]

JavaDoc知らないのかな？“１つ１つの小さなクラスに対して仕様書を書くのは完全に無駄だ。それに相当するテスト仕様書を書くのは、COBOLの時代だってしていない。”

[tbpg]

カバレッジだけ通して頑なにassertを書かない開発者いたなー（遠い目） "カバレッジを通すためだけに、プログラムを呼び出すためだけのプログラムがそこに書かれていたのだ"

[akachochin]

きょん氏の記事の引用元。私見では、【「テストコードの詳細設計仕様書(How test?)」は必要でなく、「テストコードのAPI仕様書(What test?)」は必要。もちろん手作りExcelでなく自動生成。生成物の質担保はレビューで】かな。

[kawa-_-kawa]

参加したDevOpsハッカソンで言われていたことの具体的内容。今思えばせっかくTFS使っていたのだからテストレビューについてレビューしても面白かっただろうな。

[kyon_mm]

だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？

[myfinder]

“「Be Lazy」を意識すると、同じ成果に対してだんだん短い時間でやれるようになってくる”

[tanaka733]

あ、はい。 >> “しかし、ここまでしても、内容がコードとぶれる必要がある。だから、例えばRubyとかのAPI仕様書は、API仕様書から具体的なコードを読めるように工夫されている。”

[teracy_junk]

「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」

[bufferings]

この話をDevOpsハッカソン中にしてくれたんだけど、そのときの発想が面白くて、「この人と仕事したら大変だろうけど、気持ちの良い大変さだろうなー」って聞いてた。