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

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

僕の主張

本記事は僕の実験結果︵経過報告︶であり、正解でも押し付けるものでもないです。ただし、提案としてはいいと思う。的な。牛尾さんの記事を読んだ時の僕の主張︵思い︶は次の4つです。 (一)基本姿勢は﹁いいぞ、牛尾さんもっとやれ！﹂です。 (二)﹁恐らく一番簡単なのはそれが出来る人にレビューして貰うことだろう﹂のところは、ハッキリと﹁Excelにコピペされた内容が正しいかそもそもレビューできないお前にレビューできる単体テストなんてこの世に存在しない﹂と言ったほうがいいと思う。 (三)そもそもここの登場人物たちの単体テストはうまく機能しているのだろうか？E2Eテストより小さいものは単体テストと言っているのだろうか？ (四)なら、良いテストであるかどうかを考えるとはどういうことであるのか？ 2と4が主に言いたいことなんですが、2はハッキリとさせたほうがいいと思いました。︵ここで言われているマネージャーがどうあるべきかという点において︶単体テストはAPIに近い場所であるほうがいいし、だから単体テストやプロダクトコードからドキュメントを生成するように頑張っている人たちがこのようにいるのである。そして受け入れているのだ。というような内容が書かれていましたが、全くそのとおりだと思います。ですが、それの良し悪しを判断できるのであればそもそも品質の良いテストコードであれば読めます。読めないときに、テストコード設計の良し悪しを話せないなら、そのスキルがないと判断してよいはずです。そのときに、どういった書き方だったら読める、読みやすい、ほしいものは何かという話をできない関係であるというのは、それチームとして機能していないでしょって感じが。で、4について僕が普段考えていることを書きます。

テスト(コード)レビューの方針

基本的には次のように見ています。 ●誰がどのように使いたいのか表現されているか？ ●どのような性質を満たしているか明確に表現されているか？ ●テスト対象外をどのように表現されているか？ ●過去のバグを踏まえて表現されているか？ ●よく調べるけど仕様だけど調査に時間のかかるシナリオは表現されているか？ ●どうでもいいテストはどうでもいいように表現されているか？これで網羅できていないんですが、ドラフト版なので。

誰がどのように使いたいのか表現されているか？

単体テストと呼ばれているものであれば﹁こんなロジックを成立させるためのAPIですよー﹂というのがわかるのがいいです。そうでなければ大して意味が無い。ここらへんが Cope が言っている単体テストがムダになる理由とつながっているんじゃないでしょうか。コンパイラさんが貧困なために作るテストはあるが、そういったものはリリースする前にはなくなっているのが望ましいです。︵作っている最中には必要になることがおおい︶また、共通的にほしくなるなら、それはチェッキングフレームワークだったり、フレームワークとして開発するのがいいんじゃないですかね。簡易には静的解析ツールがそうだと思います。テストが失敗した時に﹁何が原因で失敗しているのか﹂を早く切り分けることがとても重要であり、﹁コンパイラをサポートするための記述﹂なら﹁アプリケーションロジックを表現するもの﹂とは切り離して記述しておくことで、問題を切り分けやすくなるはずです。

どのような性質を満たしているか明確に表現されているか？

これは端的に言えばそれ、どんなグラフとかデシジョンテーブルを表現しているの？っていう感じです。別に単体テストだけで担保する必要はないんですけど。でも、往々にして僕がほしいのは﹁システムが持つデシジョンテーブルはこれくらいあって、そのうちこれはこの方法で担保していて、ここは冗長化してあって。。。﹂みたいにわかるテストシステムがほしい。それを簡易にするようなテストウェアはまだ出会ったことがないので、MSさんとかIBMさんとか作ってくれませんかね！そういった意味で、私はあまりExcelというかSpreadSheet系は別にそんなに悪い方法じゃないなぁと思う。︵Google Apps系はスクリプト含めて柔軟性高そうってイメージもある︶ただ、それを表現することを諦めるというか、理想とは程遠いツールを掲げて﹁このツールに従わないやつはクソだ﹂というエンジニアとかは﹁はぁ？近寄らないでー﹂とか言いたくなる。どうやって理想に近づけるかとか、どこを妥協するのがチームにとってよいかの話をしましょう。

テスト対象外をどのように表現されているか？

コメントでもテストダブルでも名前空間でもいいので、このテストはここまでしか見ないよ。少なくともこれは見ないよ。ということをどれくらい表現できているか。は重要です。︵全ては表現できないけど︶少なくとも対象の境界に位置する部分くらいは例えば﹁この前提ですよ﹂というのが表現できているといいです。テストダブルは結構すきじゃないのですが、テストダブルを使うと﹁こいつおれのテスト対象外ですよー﹂という表現になるのでいいと思います。本来的には、テストだけでも﹁シナリオ(機能)のDAGで表現できる﹂のが望ましいと思うのですが、まぁそうもいかないこともあるので、対象外となりそうな境界くらいは書いておきましょうという感じです。

過去のバグを踏まえて表現されているか？

チーム内で発見したバグであったり、いつもやりがちなーという部分はできればテストとして表現されているとよいです。レビューしていると﹁あー。この前みたいなバグのケースって確認してあるー？﹂みたいなの。そういうの最初からやっておいてくれー的な。いつもやりがりなケースがそれなりある場合については、もう簡単に自動生成できるとかスニペット用意するとかフレームワーク化するとかしたほうがいいと思います。

よく調べるけど仕様だけど調査に時間のかかるシナリオは表現されているか？

これも Test As Document の考え方ですが、FAQとしてテストを表現しておくと便利です。その際にはコードでもコメントでもパッケージでも方針でもいいので、そういった意図を表現しておくのがセットですが。意図が書かれていない奴は結局、失敗した時に対処に困ってしまいます。

どうでもいいテストはどうでもいいように表現されているか？

作るために必要だったけど、別の方法で担保できるようになったテストケースはいつでも削除していいようなことがわかるようになっていると嬉しいですね。僕がいつもやるのは名前空間でわけていたりします。 ●developer.guide <- 開発者向けのテスト ●developer.guide.note <- 開発者向けのテストをするときにできたなにか。捨てていいやつ ●developer.guide.discussion <- 開発者向けのテストで提案するための名前空間。捨てていいやつ ●user.guide <- ユーザー向けのテスト ●user.guide.note <- ユーザー向けのテストをするときにできたなにか。捨てていいやつみたいな！