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
Rikuto Sato
March 28, 2025
0
18
「テストコードのスタイルガイド」を作った理由
Rikuto Sato
March 28, 2025
Tweet
Share
More Decks by Rikuto Sato
See All by Rikuto Sato
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
9
2k
useReducerいつ使う?
riku929hr
1
6k
Git勉強会
riku929hr
0
210
Featured
See All Featured
Speed Design
sergeychernyshev
32
1.1k
Building an army of robots
kneath
306
45k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
332
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Raft: Consensus for Rubyists
vanstee
140
7k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Code Reviewing Like a Champion
maltzj
524
40k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
The Cost Of JavaScript in 2023
addyosmani
51
8.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
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 おわり