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
420
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
Case Study: Concurrent Counting
ennael
PRO
0
110
How CERN serves 1EB of data via FUSE
ennael
PRO
0
16k
ラブグラフ紹介資料 〜プロダクト解体新書〜 / Lovegraph Product Deck
lovegraph
0
14k
それでもやっぱり ExpressRoute が好き!
skmkzyk
0
270
Oracle GoldenGate 23ai 導入Tips
oracle4engineer
PRO
1
270
入社半年(合計1年)でGoogle Cloud 認定を全冠した秘訣🤫
risatube
0
150
【shownet.conf_】トポロジ図の歩き方
shownet
PRO
0
510
OPENLOGI Company Profile for engineer
hr01
1
12k
Oracle Database 23ai 新機能#4 Real Application Clusters
oracle4engineer
PRO
0
150
Oracle Database 23ai 新機能#4 Application Continuity
oracle4engineer
PRO
0
120
Webセキュリティのあるきかた
akiym
31
9.8k
Efficient zero-copy networking using io_uring
ennael
PRO
0
350
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Writing Fast Ruby
sferik
626
60k
Infographics Made Easy
chrislema
239
18k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
What's in a price? How to price your products and services
michaelherold
243
11k
The World Runs on Bad Software
bkeepers
PRO
65
11k
In The Pink: A Labor of Love
frogandcode
139
22k
The Brand Is Dead. Long Live the Brand.
mthomps
53
38k
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.5k
Become a Pro
speakerdeck
PRO
24
4.9k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する