もちゅろぐ

お辞儀して顔上げたらおっさんになっていた子どもが大人を目指します。

カバレッジがもたらす災い。カバレッジ率なんてゴミ箱に捨てて、みんなで飲みに行け。

今働いている会社で、そういったことにダイレクトに巻き込まれたわけじゃないですが、 単体テストカバレッジについて思うことを書きました。

テスト添削以外でもリリース速度を上げる方法はありますが、ここではそれは記載していません。 ここで言いたいのは、

  • 無駄なテストは計画的に優先度下げればよい。
  • カバレッジだけでは、テストの優先度判断ができない。

の2点になります。

リリーススピードとプロダクト品質の天秤

早くプロダクトをリリースするには、必要な作業だけを行えばよい。 プロダクトの品質保証も最小労力で最大効果を得られるテストを行い、重大な障害に繋がらない保証になれば良い。 細かい障害は、その後のサイクルで解消すれば良い。

つまりプロダクトバックログのストーリーとして、残りのテストストーリーを用意し、POに説明、そして判断してもらえば良い。 そうすることで、予めテストストーリーを落とすことによる障害を許容され、あとでゴタゴタに巻き込まれない。

そうすることで開発者は、重要な要素、最低限のテストのみでリリースにすることができ、リリーススピードより優先度の低いテストを落とし、 期待されるリリーススピードにつなげることができる。

しかし、POとは別にBOやリリース承認者、ビジネスサイドのCTOがリリース承認に立ちはだかる。

単体テストはエンジニアのためにあり、経営者やマネジメント、リリース承認者のためではない

上の人達にとって、単体テストの検証内容は重要ではなく、テストの網羅率(カバレッジ)しか興味がない。 そもそもの問題として、それが手軽に測れるし、それ以外が手間という原因もある。

よくあるカバレッジの使われ方

カバレッジ率が一定水準より以下だと、理由を求められる。 開発者は、わざわざカバレッジが低い所を洗い出し、一つ一つに説明をしなければいけない。 これはとても面倒で価値を産まない作業で、上の人達を説得するしか役に立たないものだ。

そもそもカバレッジが高ければ良いと定めたルールが歪んでいる。 カバレッジとはテスト結果による網羅性という副産物であって、テストによって得られる安定性・信頼性を証明したものではない。

カバレッジはそれ単体では信頼性にかける

グレーボックス観点で重複のない組み合わせが10個あったとして、その10個全てが同一処理を通る場合、 カバレッジは、組み合わせのうち1個を実施すればカバレッジとしては十分だが、テストでは残り9個実施する必要がある。

開発者はカバレッジにのまれてはいけない

開発者としては、10時間リソースがあったとしたら、カバレッジ率を一定水準上げる作業に10時間より、 複雑な処理の単体テストに10時間費やしたほうが、安心するし、ビジネスダメージも抑えられる。

これを事業部・会社の決まりだからと言って、カバレッジを水準を超えることを優先したテストを書いてしまうと、 単体テストがゴチャゴチャしたものになるし、本当にテストしたほうがいいケースを見失うことになる。

結果、障害に繋がり最後には開発者が責められることになる。

承認者と信頼関係を結ぶほうが早い

開発者がカバレッジ率を通して承認者から信頼してもらうよりも、開発者が直接承認者と信頼関係を結べるほうが話が早い。

そのほうが最終的には、「君が大丈夫だと思っているなら、僕は君を信じるよ」というベースの上で話が進むので円滑にことを進められる。

当然信じてもらっているからには、それだけの品質を保証する必要がある。

障害が発生したときには、きちんと原因追求を行い、そこがただの設定画面なのか、会員登録画面なのか明確にし報告することは重要だ。 それを怠ると、信頼は下がり数値的判断ができるような資料を用意せざる得なくなる。