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
510
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
Terraform Stacks入門 #HashiTalks
msato
0
360
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
120
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
180
Application Development WG Intro at AppDeveloperCon
salaboy
0
200
"とにかくやってみる"で始めるAWS Security Hub
maimyyym
2
100
TypeScript、上達の瞬間
sadnessojisan
48
14k
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
【LT】ソフトウェア産業は進化しているのか? #Agilejapan
takabow
0
110
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.4k
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
3
640
SSMRunbook作成の勘所_20241120
koichiotomo
3
170
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
560
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Designing for humans not robots
tammielis
250
25k
Making Projects Easy
brettharned
115
5.9k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Git: the NoSQL Database
bkeepers
PRO
427
64k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Bash Introduction
62gerente
608
210k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
KATA
mclloyd
29
14k
Producing Creativity
orderedlist
PRO
341
39k
Thoughts on Productivity
jonyablonski
67
4.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する