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
120
ローンチ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
760
はじめてのフロントエンド・バックエンド分離 / 2020-08-25 RAKUS Meetup
westc
3
2.3k
売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話 / JJUG CCC 2019 Spring
westc
2
2.7k
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
Building a Scalable Design System with Sketch
lauravandoore
456
32k
How to name files
jennybc
65
93k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
40
4.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
14
1.6k
What's new in Ruby 2.0
geeforr
337
31k
Producing Creativity
orderedlist
PRO
337
39k
How STYLIGHT went responsive
nonsquared
92
4.8k
It's Worth the Effort
3n
180
27k
Code Reviewing Like a Champion
maltzj
514
39k
The Invisible Side of Design
smashingmag
294
49k
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
新規コードへの対策 テスト指針の遵守をレビュー観点に追加 • カバレッジの推移をグラフ表示
おわりに • コード量・メンバー数ともにまだ規模が小さいためリカバリーが効きやすい • 割れ窓理論にならないよう、今のうちに整備を進めたい • プロダクトの状況に沿ったちょうどいい作成指針を見極めたい
ありがとうございました