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
テストデータを貯めて感じたこと
Search
Yoshiori SHOJI
August 22, 2023
Programming
12
4.3k
テストデータを貯めて感じたこと
https://toruby.connpass.com/event/286678/
の発表資料です。
Yoshiori SHOJI
August 22, 2023
Tweet
Share
More Decks by Yoshiori SHOJI
See All by Yoshiori SHOJI
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
430
ソートできるUUID v7をJavaで使うときの話
yoshiori
8
7k
Go Down Rockin'
yoshiori
27
13k
エンジニアリング x US 海外とのコラボレーション
yoshiori
3
2.1k
未完成な技術と歩む道のりでの 試行錯誤
yoshiori
0
160
DevOps, Immutable Infrastructure, Microservices and Chaos Engineering
yoshiori
13
2.3k
Change the recipe's world
yoshiori
3
1.4k
Cookpad awakens
yoshiori
5
7.6k
Failure teaches Success
yoshiori
42
11k
Other Decks in Programming
See All in Programming
リアクティブシステムの変遷から理解するalien-signals / Learning alien-signals from the evolution of reactive systems
yamanoku
3
1.2k
Signal-Based Data FetchingWith the New httpResource
manfredsteyer
PRO
0
170
リアルタイムレイトレーシング + ニューラルレンダリング簡単紹介 / Real-Time Ray Tracing & Neural Rendering: A Quick Introduction (2025)
shocker_0x15
1
300
Being an ethical software engineer
xgouchet
PRO
0
210
サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara
77web
4
640
地域ITコミュニティの活性化とAWSに移行してみた話
yuukis
0
240
プロダクト横断分析に役立つ、事前集計しないサマリーテーブル設計
hanon52_
2
440
AIコーディングの理想と現実
tomohisa
20
27k
gen_statem - OTP's Unsung Hero
whatyouhide
1
200
「”誤った使い方をすることが困難”な設計」で良いコードの基礎を固めよう / phpcon-odawara-2025
taniguhey
0
140
Vibe Codingをせずに Clineを使っている
watany
17
6.2k
Agentic Applications with Symfony
el_stoffel
2
300
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
20k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Navigating Team Friction
lara
184
15k
Building Adaptive Systems
keathley
41
2.5k
Building Flexible Design Systems
yeseniaperezcruz
329
38k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Unsuck your backbone
ammeep
670
57k
Designing Experiences People Love
moore
141
24k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
119
51k
Transcript
テストデータを貯めて 感じたこと 〜テストの健全性とコンテキストに紐づく重要度〜 Aug 2023 toRuby Presented by Yoshiori Shoji
2 2 @yoshiori
テストのデータを 貯めている 3
ビルドのデータや、テスト実行結果の データなどいろいろなデータを僕たち は蓄積している。 このデータをもっと活用できるので は? 4
5 コード一行だけ修正した。 なんで全件テストを通す必要 があるの?? “
あなたはちょっとした修正で影響範囲 はないと思っているかもしれない。 でも、予想外の部分でエラーが出る可 能性はある。 6
ではそのエラーが出る可能性は 何%ですか? 7
8 あー、そのテストたまに失敗 するから再実行してみて! “
ではそのたまに失敗する可能性は 何%ですか? 9
テストの健全性 10
テストのデータを貯めて見えてきたもの ▶ 不安定なテスト(Flaky Tests) 変更がないのに成功したり失敗したりするテスト Googleですら全体の16%はFlakyだと言っている(多すぎん?) ▶ 失敗したことがないテスト(Never Failing Tests)
今まで失敗したことがないテスト ▶ 時間掛かるテスト(Longest Tests) 純粋にコスパ悪い ▶ 良く失敗するテスト(Most Failed Tests) Flakyとは違い変更が無ければ結果は変わらないが、よく失敗する 依存関係や変数が多すぎるのかもしれない 11 11
このへんがテストの健全性、 つまりそのテストが有効かどうかに 繋がっているのではないか? 12
健全性を取り戻すための指針 より良いテストコードを書く ▶ 不安定なテスト(Flaky Tests) 不安定指数が高いもの、解決方法は様々 ▶ 失敗したことがないテスト(Never Failing Tests)
本当に必要か、他でテスト出来ていないか ▶ 時間掛かるテスト(Longest Tests) これは全てに乗算で影響しそう ▶ 良く失敗するテスト(Most Failed Tests) 依存関係や変数を見直す。テストしないで良いこともテストしていない か 13 13
このへんを指針に テストの健全性を保つために たまにメンテナンスしたい 14
コンテキストによる テストの重要性 15
テストの 重要度 優先度が 状況によって違う 16
テストの重要度?優先度?が 状況によって違う みんなで共通認識持てるように下記のよう環境を想像して ▶ 全部のテストを実行すると2時間かかる ▶ テストを実行するタイミングは2つ ▶ PullRequestレビュー時のテスト(pre-merge) ▶
いわゆるトピックブランチ ▶ リリース直前のテスト(post-merge) ▶ mainブランチとかreleaseブランチとか言われるやつ 17 17 * 気になってモヤモヤしている人に先に伝えるとスモークテストについては後でちょっとだけ触れます
PullRequestレビュー時のテスト テストの信頼度 < 時間 ▶ 今まで落ちたことがないテストとか実行する必要あんまりない ▶ 時間がかかるテストもコスパ悪い ▶ 単純に同じ失敗率なら10分かかるテスト1個より1分で終わ
るテスト10個実行したい(失敗率とかわかるなら) ▶ 壊れやすいテストもそれなりに有用 ▶ もちろん時間との兼ね合いだけど ▶ 不安定なテスト(Flaky Tests)はノイズ 18 18
リリース直前のテスト テストの信頼度 > 時間 ▶ 100%の信頼度が欲しい ▶ 全てのテストを実行したい気持ちが強い ▶ ちょっと政治的だけどテストしたという事実が重要なことも
▶ 例: 金融系なのでお客さんの環境に出す前に確認をしたかが大事 ▶ 不安定なテスト(Flaky Tests)はノイズ 19 19
という環境で PR時には実行したくないけど リリース時には実行して欲しいテスト とかある 20
例: DBのRead-Write splittingのテスト ▶ 特性 ▶ このテストは最初にマージされてから失敗したことがない ▶ 実際のDBを使うので1テストあたりにかかる時間は多い 21
21
例: DBのRead-Write splittingのテスト 関係なさそうな場所の修正のとき例えば文言修正のPR ▶ PullRequestレビュー時のテスト ▶ 実行しなくていい、数秒で終わるならまだしも時間のかか るテストだしコケたこと無いし時間の無駄 ▶
リリース直前のテスト ▶ 結構ロジックの根っこ部分なので必ずテストしておきたい ▶ 壊れていない事を確認したい 22 22
例: DBのRead-Write splittingのテスト 関係ある場所の修正のとき例えばsplitのロジック変更 ▶ PullRequestレビュー時のテスト ▶ めっちゃ重要 ▶ ただ、ローカルで絶対テストしてからpushしてる?
▶ だったらもしかしてPRでは実行しなくてよい? ▶ まぁ、流石に実行したい。人はミスするしローカルで実は違う奴テスト実行してた とかあるある ▶ シェルの履歴から実行してて実は違うの実行してたとか 23 23
100%コケるテストはわかりやすく邪魔 だけど 100%成功するテストもある意味ノイズ になりうる (今の例の関連していないPRのように) 24
昔から所謂スモークテストとかサニ ティテストとかの概念はあった。 受け入れテストの前に浅くとか一部と かテストしたい。ので人が選別して一 部をテストしていた。 25
ここからCM 26
もっとハッキリ言うと 失敗するテストだけ実行したい -> それLaunchableで出来るよ 27 広告
失敗するテストだけ 実行するは誇大広告 だけど、失敗率の高 いテストを実行でき るので例えば10分テ ストすれば97%の信 頼度ですよとか選択 できる 28 広告
CMおわり 29
どのようなテストが 良いテストなのか? (ここからまだ答えなく悩んでる話) 30
さて、状況によって優先度が違うのは 理解した。 だんだんテスト書くときも 色々なことを意識するようになった。 31
例えばよく失敗するテスト ▶ 不安定なテスト(FlakyTest)とは違う ▶ 何かしらの変更がないと結果は変わらない ▶ Flakyなテストは同じコミットハッシュで成功したり失敗し たりする ▶ 依存関係が多いテストとも言える
▶ ちょっと変更するだけで失敗する ▶ テストに関連する変数が多い 32 32
これは良いテスト? 33
依存関係の大小への個人的想い 依存関係の多いテスト ->基本嫌い 依存関係の少ないテスト->素晴らしい 34
依存関係の少ないテストは素晴らしい ▶ Unit test とか ▶ 一つのことをテストする大事 ▶ きちんと設計すれば依存少なく書ける ▶
美しいと感じる ▶ しかし別の場所を修正しているときは重要度低い ▶ その場所を弄っているとき以外は無駄なテストになりがち ▶ 依存少なく書いていれば 35 35
例: メールアドレスをマスクする処理のロジックのテスト ▶ y*****
[email protected]
的なやつ ▶ 最初の実装時には絶対に書きたい ▶ 例えば1文字の時とか2文字のときとかの境界値のテスト ▶
不安を元に書くテスト ▶ 所謂 Development Test ▶ ここ以外を弄っているときはまず壊れない ▶ 他の部分の修正のPRでは極論実行する価値がない 36 36
依存関係がそれなりにあるテスト ▶ もちろんすぐに壊れるようなテストはメンテコスト高すぎなので論外 ▶ なんとなく俺の中ではRailsで言うController testくらいのやつ ▶ postアクセスしてアサインされている変数が適切かとか ▶ System
testになるとちょっと壊れやすすぎな気がする ▶ 動作確認が面倒くさいから書くことが多い ▶ フォームの複数の項目により処理が色々変わるとか ▶ つまり変数が多い ▶ 毎回ブラウザでポチポチが面倒くさいからテスト書く 37 37
依存関係がそれなりにあるテスト ▶ どちらにしても僕個人としてはあまり美しさを感じない ▶ 不安ではなく面倒くさいから書くテスト ▶ ユーザー影響ある時に適切に失敗するので役に立つ ▶ これは結構PullRequestのときも重要度高い ▶
もちろんリリース直前のときも重要度高い 38 38
これは良いテスト? な気もする 39
何となく僕の中でモヤモヤと下記が成り立ちつつある ▶ 不安を元に書くテスト ▶ 依存関係少ない ▶ 美しいと感じる ▶ 動作確認めんどくさいから書いたテスト ▶
依存関係多め、変数多め ▶ 美しくないと感じる ▶ でもPullRequestの時とかは特に後者のほうが重要なことが多い ▶ 美しいと思ってないほうが重要なのでちょっと嫌悪感 ▶ まぁしょうがないんだけど 40 40
でもController Test落ちた時に 原因箇所のUnit Testなかったら ムカつく!!!! 41
さて 42
テストのデータを集めて色々やるの楽しい ▶ データを見るようになったことで今までテスト書いていた時に比べて 重要度とか依存度とかを意識するようになった ▶ 書いたテストの健全性的な側面 ▶ 時間とともに変わってくる ▶ 昔はそうでなかったものがFlakyになってきたり
▶ 見える化はとても良い ▶ それLaunchableで(ry ▶ 色々妄想捗る 43 43
テストのデータを集めて色々やるの楽しい ▶ 一方でまだモヤモヤ言語化出来ていないことも多い ▶ ピーキーなテストと適切に落ちるテストの境目とか ▶ あまり美しくないと思っているテストのほうが 俺のことを助けているという事実とか ▶ 開発時には美しいテスト助かってるのよ!!
44 44
オチはなし! モヤモヤを吐き出しに来たので! 45
最後に ▶ やっぱりSoftware TestingとかDevelopment Test とか楽しい ▶ 今は趣味と仕事が一致していてとても楽しい ▶ 一方で会社の業務と繋がってるとこういう話を出来る場
所が少ない ▶ 会社の話が出るならスポンサーセッションでとか言われる ▶ ということで今日は本当にありがとうございます!!! 46 46
Thank you! 47