Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
「テストコードのスタイルガイド」を作った理由
Search
Rikuto Sato
March 28, 2025
51
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
「テストコードのスタイルガイド」を作った理由
Rikuto Sato
March 28, 2025
More Decks by Rikuto Sato
See All by Rikuto Sato
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
8
2.4k
useReducerいつ使う?
riku929hr
1
6.7k
Git勉強会
riku929hr
0
290
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Paper Plane
katiecoart
PRO
5
54k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
2
410
Producing Creativity
orderedlist
PRO
348
41k
Code Reviewing Like a Champion
maltzj
529
40k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Darren the Foodie - Storyboard
khoart
PRO
4
4k
Evolving SEO for Evolving Search Engines
ryanjones
0
330
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.2k
Transcript
「テストコードのスタイルガイド」を 作った理由 OPENLOGI TGIF 1 2025/03/28 rikuto(@riku929hr)
この資料について なぜ「テストコードのスタイルガイド」を作ったか その根底にある想いだけ聞いてほしい!! 2
コーディング規約を作る予定はなかった 3 • リファクタしたらテストが落ちる • リリース後にバグが⾒つかる • CIが遅い etc…
• リファクタしたらテストが落ちる • リリース後にバグが⾒つかる • CIが遅い etc… コーディング規約を作る予定はなかった 4 なんとかしたい!!
でも⾃動テストよくわからん!! 学んでみよう! というのが事の始まり
テストする理由(phpcon2024登壇資料より) 5
変更容易性がもたらすもの 6 プロダクトを迅速に変化させる より顧客課題を解決でき、プロダクト‧会社が成⻑する (Googleのソフトウェアエンジニアリング 11章 テスト概観)
「テストコードのスタイルガイド」 テストコードの質の向上以外の もう⼀つの狙い 7
スタイルガイドのもう⼀つの狙い プロダクションコードの質の向上 8
良いテストを書くには 9 (単体テストの考え⽅/使い⽅ p22) (レガシーコードからの脱却 1.1.レガシーコードとは何か?)
良いテストを書くには 10 「良い」テストコードが書ければ 「良い」プロダクションコード
プロダクションコードのガイドライン 合意形成が難しい、時間がかかる テストコードのガイドライン たぶん関⼼がそんなに⾼くない プロダクションコードに⽐べれば、合意形成が容易 「テストコードのスタイルガイド」の隠し意図 11 テストコードにゆるいガイドラインを設けることで、 暗黙の「プロダクションコードのガイドライン」ができるはず!
質とスピードは相互作⽤する https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition?slide=43 12
つまり、本当にやりたいのは 13 テストコードに⼀定のレギュレーションを設けて、テストの質を上げる (あくまで理想論です) 間接的にプロダクションコードの質が上がる 質の⾼いコードとテストにより、すぐに⼤胆な変更ができるようになる プロダクトが事業環境の変化に素早く追従する
やりたいけど、できていないこと スタイルガイドではカバーしきれない課題への対処 ガイドライン定着のためのAIによる⾃動レビュー ⾃動テストの⾼速化、サイズダウン戦略… 14
まとめ プロダクトを中⻑期的に成⻑させていくには変更容易性が不可⽋ ⾃動テストは変更容易性を⽀える⼤きな要素の⼀つ テストコードを良くするためのレギュレーションがあれば、 プロダクションコードの質も上がる(はず) コードの質が上がればデリバリーのスピードも上がり、 プロダクトの成⻑も加速する(させたい!) 15
16 おわり