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
Kawahara Ryoma
September 17, 2024
Technology
0
690
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
150
LLM時代の検索
shibuiwilliam
2
380
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
2
200
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
550
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
3
22k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
190
【LT会登壇資料】TROCCO新コネクタ「スマレジ」を活用した直営店データの分析
kazari0425
1
110
american aa airlines®️ USA Contact Numbers: Complete 2025 Support Guide
aaguide
0
320
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
データ基盤からデータベースまで?広がるユースケースのDatabricksについて教えるよ!
akuwano
3
130
CDK Vibe Coding Fes
tomoki10
0
120
Lakebaseを使ったAIエージェントを実装してみる
kameitomohiro
0
140
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Speed Design
sergeychernyshev
32
1k
Rails Girls Zürich Keynote
gr2m
95
14k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Statistics for Hackers
jakevdp
799
220k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
How STYLIGHT went responsive
nonsquared
100
5.6k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
A better future with KSS
kneath
238
17k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する