Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ローンチ1年目プロダクトのテストコード事情 / 2021-08-25 devtestlt
Search
west-c
August 25, 2021
0
140
ローンチ1年目プロダクトのテストコード事情 / 2021-08-25 devtestlt
https://rakus.connpass.com/event/218754/
west-c
August 25, 2021
Tweet
Share
More Decks by west-c
See All by west-c
大規模案件における手戻りを防ぐ要件定義・開発事例 / 2022-11-09 RAKUS Meetup
westc
0
1.1k
はじめてのフロントエンド・バックエンド分離 / 2020-08-25 RAKUS Meetup
westc
3
2.6k
売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 / JJUG CCC 2019 Spring
westc
2
3.1k
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9.1k
We Have a Design System, Now What?
morganepeng
51
7.4k
Practical Orchestrator
shlominoach
186
10k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Navigating Team Friction
lara
183
15k
RailsConf 2023
tenderlove
29
1k
Scaling GitHub
holman
459
140k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Building Applications with DynamoDB
mza
93
6.2k
A better future with KSS
kneath
238
17k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
440
Transcript
ローンチ1年目プロダクトの テストコード事情 2021.08.25 開発×テスト LT会 #devtestlt @west_c_
自己紹介 west-c (@west_c_) • 2015年〜:株式会社ラクス所属 ◦ 楽楽勤怠の機能開発担当 ◦ 主戦場はJava
担当プロダクトについて 楽楽勤怠(勤怠管理サービス) • 2020年10月にローンチ ◦ 開発自体は2020年初頭からスタート • 開発経験豊富なメンバーの比率が高め • 新しいメンバーも徐々に参画してきている
ユニットテストにまつわる課題 ユニットテスト作成指針がふんわりしている • コアドメインの機能:ドメインに精通したメンバーが作成した テスト項目書をもとに実装 • それ以外の機能:大方針をもとに実装者が ”いい感じ” に実装 ◦
→どれだけ網羅できているか把握できていない
ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか? • 今後十分にユニットテストを作成するためにどうするか?
ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか? • 今後十分にユニットテストを作成するためにどうするか?
現状調査 • JaCoCoでプロダクトコードのテストカバレッジを計測
現状調査 • 結果: ◦ C0(命令網羅率): 約90% ◦ C1(分岐網羅率): 約80%
現状調査 • 結果: ◦ C0(命令網羅率): 約90% ◦ C1(分岐網羅率): 約80% •
思った以上に良い結果 • 極端にカバレッジが低いパッケージもいくつかある
既存コードへの対策 • カバレッジが低いパッケージのテスト作成 • 測定で発見したデッドコードの除去 • 【今後の課題】各種分析結果をもとにテスト作成指針の整備 ◦ 不具合分析結果からどういった観点のテストが漏れがちか
ユニットテストにまつわる課題 • 現在のユニットテストの網羅率は十分なのか? • 今後十分にユニットテストを作成するためにどうするか?
新規コードへの対策 カバレッジ指標の策定 • C1 Coverage: 80%(現状維持) • ロジックの正当性担保が目的のためC1で測定 • 本質のロジックのテストに注力するために、100%は目指さない
◦ equals(), hashCode() などの分岐網羅をがんばらない
新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • GitLabのMerge Request上に網羅状況を可視化 https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html
新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • GitLabのMerge Request上にカバレッジを表示 https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request
新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • カバレッジの推移をグラフ表示
おわりに • コード量・メンバー数ともにまだ規模が小さいためリカバリーが効きやすい • 割れ窓理論にならないよう、今のうちに整備を進めたい • プロダクトの状況に沿ったちょうどいい作成指針を見極めたい
ありがとうございました