開発チームがカバレッジ率を意識するようになった話

お疲れ様です!まっちゃんです!

皆さん、ちゃんとテスト書いていますか?
とあるスプリント振り返りで、Scalaプロジェクトのテストに対する認識の差が議題に上がりました。
本日はその問題からどのように改善へと持っていこうとしているのか。という事を書いていきます。

当時Problemで上がった内容

問題
  • テストコードの網羅率(カバレッジ率)が低い
  • カバレッジレポートが出ないプロジェクトがある
原因
  • 単体テストが網羅できていない
  • テストコードを書いているものの、一部のみ
  • ローカルでテスト実施時に出力されるカバレッジレポートを見ている人がほぼ居ない
    • レポートを知っている人がほぼ居ない、共有できていなかった
  • プロジェクトによって、カバレッジ率を表示していないものがある

それぞれ詳細に見ていきます。

テストコードの網羅率(カバレッジ率)が低い

メイン案件のプロジェクトのカバレッジは約40%でした。
テストに対する認識にズレがあり

  • 全ての層を網羅するのが当たり前、
  • 他プロジェクトではRepository層までしか網羅していないからそこまでを実装すればOK

という、二分化されていました。

カバレッジレポートが出ないプロジェクトがある

基本案件を進める際にはローカルでテストを実行し、問題なければリモートへpushするフローを行っていました。
Scalaでは ScoverageSbtPlugin を用いれば ./sbt.sh clean coverage test coverageReport coverageAggregate といった方法でローカルでカバレッジレポートを見ることができます。
ですが、チーム内の教育・共有不足によりローカルで見ることができるメンバーが限られていました。

メイン案件のプロジェクトではリモートも見れるように、技術改善を行うチームがGitLab Pagesを用いて対応を行っていました。
他の案件でもCIサーバー上にカバレッジレポートをデプロイして確認できる対応も行っていましたが、
その知見に対する共有がなく、ローカル・リモートともにレポートを見る方法がわからないメンバーが多く居ました。

そもそも上記に書かれた方法を行っていないプロジェクトもありました。

これは非常によろしくないです。

問題点に対してどのように解決を行っていくか

以下のアクションが上がりました。

  1. それぞれの層に対してのテストコードがある(網羅されている)状態で納品する事を前提に見積もり、開発を行う
  2. テストコードに対する網羅率を定期的にチェックする意識、抜けている部分を追加する意識を持つ (納期等の問題もある為相談しながら)
  3. Gitlabプロジェクトのカバレッジレポート表示を行う (全プロジェクト)

それぞれ

1. それぞれの層に対してのテストコードがある(網羅されている)状態で納品する事を前提に見積もり、開発を行う

スプリントプランニング、プロジェクトのリリースプランニング時に考慮が漏れていたため、考慮に入れてストーリーポイントを出し合って見積もりを決めよう!という形になりました。

2. テストコードに対する網羅率を定期的にチェックする意識、抜けている部分を追加する意識を持つ (納期等の問題もある為相談しながら)

1のアクションが達成できているかも確認を行うため、スプリント振り返りの時にカバレッジレポートを見よう!という事になりました。
すぐに予定が押さえられました。

3. Gitlabプロジェクトのカバレッジレポート表示を行う (全プロジェクト)

こちらは2のアクションで使用するため、全プロジェクトのカバレッジレポート表示を行うことになりました。
さっそくバックログのストーリーとして追加されました。

カバレッジレポート表示対応

自分はその当時のスプリントプランニングで3の対応を自ら対応したいと手を挙げ、対応することになりました。
そもそも自分はわかっていたのに、共有ができていなかったと言う負債を解消したいためでした。

やった事

まずはGitLab Pages

昔のコミットログをあさり、どのような対応を行ったのか確認後、自分の個人リポジトリで試してみました。

...

test_job:
  stage: test
  script:
    - 'sh ./ci/script/test_script.sh'
  artifacts:
    name: "${CI_BUILD_NAME}_${CI_BUILD_REF_NAME}"
    untracked: true
    paths:
      - target/
  allow_failure: false

pages:
  stage: pages
  script:
    - cp -r target/scala-2.11/scoverage-report public/
  dependencies:
    - test_job
  artifacts:
    paths:
      - public
    expire_in: 30 days

...

pagesのCI/CD後、問題なくカバレッジレポートを見ることができました。

f:id:AdwaysEngineerBlog:20180518210618p:plain

(検証なので0%のテスト結果は気にしないでください><

READMEに追加した

よくGitHubのプロジェクトで見るアレですね。

GitLabでは
[Settings] -> [CI / CD] -> [General pipelines settings] -> [Coverage report] から書き方を確認できます。

pagesでデプロイしたカバレッジレポートへの導線も追加しておきました。

f:id:AdwaysEngineerBlog:20180518211403p:plain

Confluenceで集約ページを作った

チームでは情報の集約としてConfluenceを活用しています。 複数プロジェクトをまとめてみれるように、Confluenceのiframeマクロを用いて表示する専用ページを作成しました。

f:id:AdwaysEngineerBlog:20180518212634p:plain

さっそくスプリント振り返りで見てみた

集約ページを開発チーム全員で見て現状の理解を進めました。
思った以上にカバレッジ率が高いプロジェクトもあれば、極端に低いプロジェクトもありましたorz

まとめ

スプリント振り返りで上がった問題を素早く問題解決のアクションに繋げることができたと思います。
ですが、まだまだレガシー、負債を抱えた状況なので今後はチームで徐々に解消していきたいと思っています!