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
PHPカンファレンス小田原2024
Search
Kanon
April 12, 2024
Technology
5
730
PHPカンファレンス小田原2024
Kanon
April 12, 2024
Tweet
Share
More Decks by Kanon
See All by Kanon
ソフトウェアエンジニア観に影響を与えたアニメ・漫画の名言
ysknsid25
0
22
PHP"オレ"カンファレンスの告知
ysknsid25
0
420
なぜ人は組織から去っていくのか?
ysknsid25
0
45
Laravel Sail9から導入された Mailhogの後継Fake SMTP/mailpit を使ってみた
ysknsid25
0
42
GASとChatGPTを組み合わせてZennとQiitaの急上昇記事を紹介するTwitter botを作った
ysknsid25
0
15
PHPカンファレンス関西2024
ysknsid25
0
720
アジャイル勉強法〜自分という製品を開発する〜
ysknsid25
0
140
PHPカンファレンス関西2024は神戸で過ごそう
ysknsid25
2
610
要件を理解するために、非エンジニアと一緒に業務をこなした話
ysknsid25
1
90
Other Decks in Technology
See All in Technology
Cracking the KubeCon CfP
inductor
2
270
Gradle Build Scanを使ってビルドのことを知ろう potatotips #87
tomorrowkey
2
150
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
690
ServiceNow Knowledge Learning Rise up
manarobot
0
230
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
1
580
Cypress or Playwright?
rainerhahnekamp
0
160
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
440
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
680
いいたいことちゃんという
tkengo
0
140
Grafana x PagerDuty Better Together
jacopen
1
220
Google Cloud Next '24でブログを10本書いた方法と勉強会を沸かせた方法
yasumuusan
0
320
BPStudyの200回を中心にIT業界を振り返る。そしてこれから
haru860
3
370
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
38
2.5k
Building an army of robots
kneath
300
41k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
10
1k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
A Philosophy of Restraint
colly
197
16k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
242
1.2M
Statistics for Hackers
jakevdp
790
220k
Side Projects
sachag
451
41k
Transcript
Copyright © 2023 blessing software. All Rights Reserved. Illustrated by
@amon_mikio Kanon (@samurai_se) テスト品質を向上させよう! 〜アンチパターン回避メソッド〜
1. 自己紹介 2 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio Kanon 株式会社 虎の穴ラボ samurai_se ↓詳しくは↓ • 3次元に嫁が1人います。2次元にはたくさんいます。 • 本業はKtor(Kotlin), Next.js(TypeScript)で副業がLaravel(PHP), Next.js(TypeScript) • アニメと漫画と声優ラジオが好きです • 推しは水瀬いのりさんと早見沙織さんです 個人事業 blessing software
3 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio すこしだけ宣伝
どこからきたー? 4 Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
5 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio Re: すこしだけ宣伝
アジェンダ 6 • 明日からすぐにでもできること • 継続的に取り組む必要があること • さらにその先へ・・・ Copyright ©
2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio
❗ CAUTION ❗ 7 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio
❗ CAUTION ❗ 8 • 本業と副業の事例が入り混じります ◦ 必ずしも、とらラボの事例ではないです ◦ どっちでもやっていることもあります
• 普段からいろんな言語のテストを書いてます ◦ PHPUnitに限った話ではないです ◦ が、基本PHP前提でお話します ◦ 本業ではJest/Cypress/JUnit ◦ 副業ではJest/Cypress/PHPUnit ◦ サンプルコードに言語混ざることをお赦しください・・・ Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio
🚀 明日からすぐにでもできること Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
💡 テスト名には3つの要点を含め、明確にする 10 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio X は Y のとき Z 何をテストす るか? どのような状 況とシナリオ か? 期待される結 果は何か?
💡 テスト名には3つの要点を含め、明確にする 11 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • isExistPrefecture()をチェックする アンチパターン テストコードがド キュメントの役割 を果たさない
💡 テスト名には3つの要点を含め、明確にする 12 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • isExistPrefecture()をチェックする アンチパターン エラー時、何が悪 いのかテスト名か ら判別できない
💡 テスト名には3つの要点を含め、明確にする 13 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • isExistPrefecture()をチェックする アンチパターン 具体的に何を検証 していて、期待し ていることはな に? チェックって、な にを?
💡 テスト名には3つの要点を含め、明確にする 14 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • isExistPrefecture()は存在しない都道府県を指定したとき エラーとなる • validateStringValue()はrequiredがfalseのとき空文字でも エラーとならない 日本人しかいないプロジェクトならテスト名は日本語でいい派です 例
💡 AAAパターンでテストを構成する 15 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • Arrange (準備) • Act (実行) • Assert (検証) 音楽グループではない・・・
💡 AAAパターンでテストを構成する 16 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio アンチパターン どこまでが準備でどこからが実行かわかりづらい
💡 AAAパターンでテストを構成する 17 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio 同じテストコードだけどスッキリ 一番わかりやすいサンプル→
💡 パラメタライズド テストで多様な入力値を検証 18 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio プロダクションコード DRYとは・・・? なコードになっている
💡 パラメタライズド テストで多様な入力値を検証 19 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio アンチパターン DRYとは・・・? なコードになっている
💡 パラメタライズド テストで多様な入力値を検証 20 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio 入力に対して複数の結果を得られるパターンは、網羅的 かつ一つのテストケースで検証する
💡 エラーはキャッチせず、エラーを期待する 21 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio アンチパターン 何してるのかわかりにくスギィィィィ ただしテスト名がまともだと まだかろうじて把握はできる
💡 エラーはキャッチせず、エラーを期待する 22 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio 冗長さが消え、テストメソッド名と実装が合っているのでとても直感的
🕰 継続的に取り組む必要があること Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
💡 適切なコードカバレッジを保つ 💡 24 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio
💡 カバレッジとは? 25 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • テストコードによって到達されるコード行の尺度で基準としては以下 • 分岐(Branch) ◦ 条件分岐文でどれだけの分岐条件が実行されたか • 行(Lines) ◦ コードの各行がテストスイートで実行されたか。空行や{}だけの行も含む • ステートメント(Stmt) ◦ プログラム内の命令単位。なので空行や{}だけの行は含まない • 関数(Funcs) ◦ コード内の関数が実行されたかどうか
💡 適切なコードカバレッジを保つ 26 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio • コードカバレッジは50~80%近辺を目安とするのがよさそう • 10~40% ◦ 低すぎる • 90%以上 ◦ 高すぎる ◦ プロダクトのクリティカルな実装部分を超え、重箱の隅にまで視点をおくこ とは好ましくない
💡カバレッジ閾値に満たない場合、CIを中止する 27 Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio • Laravel 9から --coverage --min=n オプションが追加 • 閾値に満たない場合、テストが失敗する • 最初は、カバレッジレポートからわかった全体カバレッジの-5%あたりか ら始める • 徐々に閾値を上げていく とにかく初期リリースまでの開発速度を重視するなら必ずしも必要な設 定ではない ただ主観だが、最初からカバレッジを高く保っていた方が あとあとリファクタやリグレッションテストの工数を減らせて デグレのリスクを下げられるので、結果的に早い
💡カバレッジ閾値に満たない場合、CIを中止する(85) 28 Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
💡カバレッジ閾値に満たない場合、CIを中止する(90) 29 Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
🔍 カバレッジレポートを精査する🔍 30 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio
💡 例えばここだけ見ているとする 31 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio CIごとではなく定期実行でカバレッジを把握しているシチュ
💡 業務上、重要な処理がここにあったら? 32 Copyright © 2023 blessing software. All Rights
Reserved. Illustrated by @amon_mikio
33 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio 💡カバレッジレポートを精査し、テストされていない領域 やそのほかの異常を検知する • 閾値はトータルカバレッジを基準にしている • それだけを監視しても、結局プロダクトの重要な部分が処理できているかは わからない • 実際にカバレッジレポートを見て、ファイルごとのカバレッジを確認するの が重要(→定期的にSlack通知したりHTMLレポートを限定URLでホスティング するのが効果的) • また、100%だとしてもそれが効果的なテストかはわからない(次で話します)
🚪 さらにその先へ・・・ Copyright © 2023 blessing software. All Rights Reserved.
Illustrated by @amon_mikio
🧪 Mutation Testによるテストコード自体の検証 🧪 35 Copyright © 2023 blessing software.
All Rights Reserved. Illustrated by @amon_mikio
36 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio Mutation Testとは コードに意図的なバグを植え付けることで、 テストコードの検証が適切に行われているか? を測定する手法
37 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio カバレッジレポートの罠 • 従来のカバレッジメトリクスは嘘をつく • 例えば以下の(極端な)テストケースを見てください
38 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio Pest(PHPUnitも?)はassertionがなければwarningを吐く
39 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio 以下の(これまた極端な)例の場合は検知できない 適切な表示がされているか? を確認できていないが、テスト が通っている しかしプロダクションコード自 体は実行されているため、カバ レッジの%は上がる
40 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio そこでMutation Testing • ここではInfectionを使う前提で話します • Mutation = 突然変異 ◦ コードを意図的に変更し、バグを植え付ける ◦ ex) a===0 を a!==0と変異させる ◦ その後テストを実行し、正しいテストが書かれて いればエラーとなるはず ◦ エラーとならなかった箇所がきちんと検証されて いないと判断できる 変異の内容 Infectionの詳細については ぺちこん関西の資料をみてね
41 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio Mutation Testingに関わる指標 • Killed ◦ 変異後、失敗すべきテストが失敗したことにより 検知された変異の数 • Survived ◦ 変異後、失敗すべきテストが成功したことにより 検知された変異の数 つまり、Survivedの数が多ければ多いほどテストコードの品質が低い
42 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio Infectionの導入 • 定期実行で全体のMutation Scoreを継続的に比較 ◦ 全体実行はかなり遅い ◦ ので週一程度でGHAを動かし、レポートをSlackに投げる • CIで差分発生箇所に対してMutation Test ◦ Mutation Scoreが一定を下回るとCIがコケる設定 ◦ 新たに追加されたコードや修正分に関しては一定以上のMutation Scoreを担保できる
🤫 実戦導入した経験談はまた別のカンファレンスにて… 🤫 43 Copyright © 2023 blessing software. All
Rights Reserved. Illustrated by @amon_mikio
44 Copyright © 2023 blessing software. All Rights Reserved. Illustrated
by @amon_mikio ご清聴、あざざました