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
740
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
クレジットカードの不正を防止する技術
yutadayo
16
7.1k
Redux → Recoil → Zustand → useSyncExternalStore: 状態管理の10年とReact本来の姿
zozotech
PRO
12
6.1k
マイクロリブート ~ACEマインドセットで実現するアジャイル~
sony
0
320
仕様駆動 x Codex で 超効率開発
ismk
2
1.4k
AWS IAM Identity Centerによる権限設定をグラフ構造で可視化+グラフRAGへの挑戦
ykimi
2
740
探求の技術
azukiazusa1
7
1.8k
機密情報の漏洩を防げ! Webフロントエンド開発で意識すべき漏洩パターンとその対策
mizdra
PRO
8
2.9k
ユーザーストーリー x AI / User Stories x AI
oomatomo
0
180
Dart and Flutter MCP serverで実現する AI駆動E2Eテスト整備と自動操作
yukisakai1225
0
410
Amazon ECS デプロイツール ecspresso の開発を支える「正しい抽象化」の探求 / YAPC::Fukuoka 2025
fujiwara3
11
2k
Flutter DevToolsで発見! 本番アプリのパフォーマンス問題と改善の実践
goto_tsl
1
450
CodexでもAgent Skillsを使いたい
gotalab555
9
4.5k
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
We Have a Design System, Now What?
morganepeng
54
7.9k
Building Adaptive Systems
keathley
44
2.8k
For a Future-Friendly Web
brad_frost
180
10k
Scaling GitHub
holman
463
140k
4 Signs Your Business is Dying
shpigford
186
22k
The Language of Interfaces
destraynor
162
25k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する