技術をかじる猫

適当に気になった技術や言語、思ったこと考えた事など。

テストコードが根付かない理由を考える(2)

前回分はこっち。

white-azalea.hatenablog.jp

前回、よく問題視されてる以下3つを揚げ、そのうち「手でやった方が早い」を考えてみた。

  • 手でやった方が早い
  • 結局手動で網羅させられる
  • 品質会計とか既存の仕組みにに乗せれないじゃん?(品質基準を図れない)

そこでの観点はいくつかあって、

  • 仕組みの問題
    • 設計手法が一筆書きではテスト可能なコードは書けない
    • 一筆書きでリリースして終わりなら、手動でやった方が楽
    • 大規模にテスター集めてスケールするという手段に出るなら、Excel で管理して網羅する方が手っ取り早い
  • 開発者の練度
    • 保守でテストを繰り返す事が、多くの開発者には他人事という意識
    • テストしやすいコードを書けない(そういう設計ができない)

までコメント欄も含め見つかった。
分類は主観なので、指摘があれば突っ込んで欲しい。
問題が分かれば対処方もあるわけで、コレを元にいつかどうすべきか論をまとめたい。

他の問題がありそうならコメントで意見が欲しい。 真にやりたいのは、テストコードを書かせる為のハードルをどうにかしたいという事なのだが、ハードルが他にもあるならそれも考えるべき対象だ。

「結局手動で網羅する」を考える

今回のテーマはこれ。
やり方はなぜ何ですが、他の流れを思いつく方はコメントにGO!

このお題も、現場で良く聞きます。
経験上は二つパターンがあって、

  • 「コードにバグが出るのに、テストコードに出ないわけないだろ」
    → テストをコードですること以前に「コード自体信用できない」って言ってるタイプ
  • 「そのテストで何が証明されてるのか見た目わからないから手動でやって」 → テストの味気なさに不安を感じるタイプ

どっちもなんと言うか…って感じですね。

「コードにバグが出るのに、テストコードに出ないわけないだろ」

「そーですね」がまぁ第一応答です(苦笑

こう言われるケースは思い込みか、やりたくない言い訳かの二択です。
なぜなにも何もない…

テストをまともに書くなら、基本的には本体とテスト、両方が正常でなければOKにはなりません。
つまり、二重チェックと言えます。
これが二重のバグで運悪く成功するという確率は低いと見るべきでしょう。

  • テストレビューしたくない
  • やりたくない
  • 何が正しいかわかってなくて、テスト時の動きでそれを見極めようとした

という所でしょう。
最後の問題のケースは論外です。コレは設計ができていないという事の証拠ですので。

前者二つは論破こそできますが、実は解決策が非常に少ない問題のような気がしますね。
だって気持ちの問題ですから…

やりたくないだけの人に書かせる方法は?

このケースではふた通りを見たことがあります。

  • まじで面倒でやりたくない
  • テストコードの効果が疑問

前者はなんでしょう? 多分すぐこの話題に触れると思いますが、テストコードを書いてレビューと実行をパスすることで網羅的テストはパスしたとみなすのは当然として…
それでも書かない人には強制するしかない?

後者のテストコードの効果に疑問というのは、正常系だけでも書いてみれば否応無く理解できると思います。
となると

「正常系だけでも書くべし」というプロジェクトルールを作る

しかないのかなと…

「そのテストで何が証明されてるのか見た目わからないから手動でやって」

これマジで言われた事あるんですよ…
で、翌々考えてみると、手動テストと違う点が見えてくるんですね。

  • スクリーンショットとかが残ってないので、そのテストが正しいのか直感的に理解できない。
  • 単体テストは機能単独のテストだけど、画面からのテストは複数の機能の組み合わせ。 機能単独の動きが「こうだ」と言って、画面仕様が満たせている確証が持てない。

まずスクリーンショットの件から考えましょう。
しかしこれは、実は単体テストの事を言っていないのですよね…

多分これは前提からして間違えてて、彼らの言う単体と言うのが、「画面」とか「結合した機能」っていうプレフィックスがつくのです。
これはオブジェクト指向のテストとしては結合テストを意味しているように思います。

単体テスト - Wikipedia

ユニットとはアプリケーションのテスト可能な最小の部品単位である、と直観的にとらえることができる。手続き型プログラミングでは、ユニットは、モジュール全体のこともあるが、より一般的には、個々の関数や手続きである。オブジェクト指向プログラミングでは、ユニットは、クラスなどのインタフェース全体だが、個々のメソッドであることもある。

とはいえ、エビデンスが残らないというのは、単体テストだと正誤表しか出てこないわけですね。
それが正しいかどうかは、テストコードレビューをするしかない。
ここで品質管理者がレビューを拒否してしまった(ないしは)ら…打つ手がありません。

と、なれば単体テストを行う条件として、

品質を判定する人が、テストコードのレビューを行う事

あとは分かりやすい様に、どの機能のどの部分のテストなのかを明示しておくのが良いと思う。
普通に考えればクラス図云々の説明なのだろうけど、個人的には、マインドマップを推したい。

言ってみれば当然の話なのだけど、コレができないならコードのテストお書いても無駄になりそうですね…。
ではもう一つはどんな感じでしょう?

  • 単体テストは機能単独のテストだけど、画面からのテストは複数の機能の組み合わせ。 機能単独の動きが「こうだ」と言って、画面仕様が満たせている確証が持てない。

ここから分かるのは、実装に近いレベルの設計を管理者が把握していないケース。
コレを防ぐ方法…なんて一つですよね多分

設計方針と、設計書をレビューするしかない

至極真っ当で当たり前の話に行き着いてしまった…。
ただまぁこの当たり前を完全にこなすのが案外難しいんですって…。