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
660
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
140
AWSを利用する上で知っておきたい名前解決の話
nagisa53
6
840
SaaS公式MCPサーバーをリリースして得た学び
kawamataryo
5
1.4k
転職したらMCPサーバーだった件
nwiizo
10
8.5k
ユーザーコミュニティが海外スタートアップのDevRelを補完する瞬間
nagauta
1
200
使えるデータ基盤を作る技術選定の秘訣 / selecting-the-right-data-technology
pei0804
9
1.5k
Kaigi Effect 2025 #rubykaigi2025_after
sue445
0
160
人間性を捧げる生成AI時代の技術選定
yo4raw
1
680
Azure × MCP 入門
ry0y4n
8
1.8k
LLMの開発と社会実装の今と未来 / AI Builders' Community (ABC) vol.2
pfn
PRO
2
160
Terraform にコントリビュートしていたら Azure のコストをやらかした話 / How I Messed Up Azure Costs While Contributing to Terraform
nnstt1
1
540
LLM アプリケーションのためのクラウドセキュリティ - CSPM の実装ポイント-
osakatechlab
0
440
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
336
57k
Optimising Largest Contentful Paint
csswizardry
37
3.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
33k
Visualization
eitanlees
146
16k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
How to train your dragon (web standard)
notwaldorf
91
6k
GraphQLとの向き合い方2022年版
quramy
46
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.5k
Embracing the Ebb and Flow
colly
85
4.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Fireside Chat
paigeccino
37
3.4k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する