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
560
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
250
Storage Browser for Amazon S3
miu_crescent
1
130
5分でわかるDuckDB
chanyou0311
10
3.2k
生成AIのガバナンスの全体像と現実解
fnifni
1
180
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
160
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
サーバレスアプリ開発者向けアップデートをキャッチアップしてきた #AWSreInvent #regrowth_fuk
drumnistnakano
0
190
20241214_WACATE2024冬_テスト設計技法をチョット俯瞰してみよう
kzsuzuki
3
440
生成AIをより賢く エンジニアのための RAG入門 - Oracle AI Jam Session #20
kutsushitaneko
4
210
Password-less Journey - パスキーへの移行を見据えたユーザーの準備 @ AXIES 2024
ritou
3
1.4k
AI時代のデータセンターネットワーク
lycorptech_jp
PRO
1
280
2024年にチャレンジしたことを振り返るぞ
mitchan
0
130
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
Raft: Consensus for Rubyists
vanstee
137
6.7k
The Cult of Friendly URLs
andyhume
78
6.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Docker and Python
trallard
41
3.1k
Code Reviewing Like a Champion
maltzj
520
39k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
What's in a price? How to price your products and services
michaelherold
243
12k
RailsConf 2023
tenderlove
29
940
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する