テスト(コード)レビューの方針 書きなぐり版 - うさぎ組

牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、

[kyon_mm]

200ブクマ超えてた！参考になれば幸いです。（書くなぐりだけど

[ryuzee]

すごくいい。すごくいい。

[masatomo-m]

Test as Documentは普段テスト最小限でええやんと思う自分でも欲しい奴。まあこれは本質的にはunit testとは離れた利用方法にも思うけど、同じ糞を二度踏まないのはモチベ的にすごく大事よね

[torazuka]

これはすごい記事だなぁ。きょんさん書籍化がんばってください。

[hinokiyo]

テスト設計って大事。 「動けばいいや」で作ってる会社もあるので要注意ですね。

[itsumu126]

19件のコメント https://t.co/SyjDCLEnSe “テスト(コード)レビューの方針 書きなぐり版 - うさぎ組”

[masaru_b_cl]

いわゆる「単体テスト」には仕様書欲しいけど、Unit Testには無くてもいいかな、位の気分。

[megascus]

JUnitで書かれたテストコードは動く仕様書だと思ってるのでこの方針には同意しかねる。

[nihonbuson]

単体テストをテスト分析やテスト設計の観点からも話している良い記事。特に「テスト対象外の表現」と「テスト捨てる」ということを意識しているところが本当に良い。

[akachochin]

牛尾氏の記事とセットで読むとわかりやすい。私見では、【「テストコードの詳細設計仕様書(How test?)」は必要でなく、「テストコードのAPI仕様書(What test?)」は必要。もちろん手作りExcelでなく自動生成で。】

[vanbraam]

"レビューしてもらえ"は同意;一番悩むのはテストコードの共通化(モジュール化).テストコードは何をやっているか分かり易くあるべき=情報のlocalityは高くあるべき,と共通化(rspecだとshare云々)をどうバランス取るか

[sylvan_l]

テスト(コード)レビューの方針 書きなぐり版

[akulog]

これは後読み #toki3_memo #開発 #テスト

[adwd118]

良さ

[ko-ya-ma]

名前空間でいずれ消すテストを見分けられるようにするのか

[kimutansk]

モックやらテストダブルを使ったテストは「～～の条件」とは書いていましたが、テスト対象外と示せば確かにより明確。なるほど。

[atsushifx]

テストの捨て方か。以外と考えたことなかったし重要な視点かも。少なくとも2.の「テストを評価できる」技術力のありなしはめいっぱい同意する

[warufuzaketaichi]

ほうほう。