ローンチ1年目プロダクトのテストコード事情 / 2021-08-25 devtestlt

https://rakus.connpass.com/event/218754/

Transcript

1. ローンチ1年目プロダクトの テストコード事情 2021.08.25 開発×テスト LT会 #devtestlt @west_c_
2. 自己紹介 west-c (@west_c_) • 2015年〜：株式会社ラクス所属 ◦ 楽楽勤怠の機能開発担当 ◦ 主戦場はJava
3. 担当プロダクトについて 楽楽勤怠（勤怠管理サービス） • 2020年10月にローンチ ◦ 開発自体は2020年初頭からスタート • 開発経験豊富なメンバーの比率が高め • 新しいメンバーも徐々に参画してきている
4. ユニットテストにまつわる課題 ユニットテスト作成指針がふんわりしている • コアドメインの機能：ドメインに精通したメンバーが作成した テスト項目書をもとに実装 • それ以外の機能：大方針をもとに実装者が ”いい感じ” に実装 ◦ →どれだけ網羅できているか把握できていない
5. ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか？ • 今後十分にユニットテストを作成するためにどうするか？
6. ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか？ • 今後十分にユニットテストを作成するためにどうするか？
7. 現状調査 • JaCoCoでプロダクトコードのテストカバレッジを計測
8. 現状調査 • 結果： ◦ C0（命令網羅率）: 約90% ◦ C1（分岐網羅率）: 約80%
9. 現状調査 • 結果： ◦ C0（命令網羅率）: 約90% ◦ C1（分岐網羅率）: 約80% • 思った以上に良い結果 • 極端にカバレッジが低いパッケージもいくつかある
10. 既存コードへの対策 • カバレッジが低いパッケージのテスト作成 • 測定で発見したデッドコードの除去 • 【今後の課題】各種分析結果をもとにテスト作成指針の整備 ◦ 不具合分析結果からどういった観点のテストが漏れがちか
11. ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか？ • 今後十分にユニットテストを作成するためにどうするか？
12. 新規コードへの対策 カバレッジ指標の策定 • C1 Coverage: 80%（現状維持） • ロジックの正当性担保が目的のためC1で測定 • 本質のロジックのテストに注力するために、100%は目指さない ◦ equals(), hashCode() などの分岐網羅をがんばらない
13. 新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • GitLabのMerge Request上に網羅状況を可視化 https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html
14. 新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • GitLabのMerge Request上にカバレッジを表示 https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request
15. 新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • カバレッジの推移をグラフ表示
16. おわりに • コード量・メンバー数ともにまだ規模が小さいためリカバリーが効きやすい • 割れ窓理論にならないよう、今のうちに整備を進めたい • プロダクトの状況に沿ったちょうどいい作成指針を見極めたい
17. ありがとうございました