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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Rikuto Sato
March 28, 2025
35
0
Share
「テストコードのスタイルガイド」を作った理由
Rikuto Sato
March 28, 2025
More Decks by Rikuto Sato
See All by Rikuto Sato
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
8
2.3k
useReducerいつ使う?
riku929hr
1
6.6k
Git勉強会
riku929hr
0
260
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.3k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Become a Pro
speakerdeck
PRO
31
5.9k
What's in a price? How to price your products and services
michaelherold
247
13k
The Pragmatic Product Professional
lauravandoore
37
7.3k
Into the Great Unknown - MozCon
thekraken
41
2.5k
How Software Deployment tools have changed in the past 20 years
geshan
0
33k
How to Think Like a Performance Engineer
csswizardry
28
2.6k
Git: the NoSQL Database
bkeepers
PRO
432
67k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
200
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 おわり