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
680
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
150
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
250
Delegating the chores of authenticating users to Keycloak
ahus1
0
130
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
770
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
4
140
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
270
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
160
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
940
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
1
240
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
2
610
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
4k
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
4
2.6k
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
231
18k
BBQ
matthewcrist
89
9.7k
A designer walks into a library…
pauljervisheath
207
24k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building Adaptive Systems
keathley
43
2.6k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する