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
製造業向けIoTソリューション提案資料.pdf
haruki_uiru
0
140
AI駆動で進化する開発プロセス ~クラスメソッドでの実践と成功事例~ / aidd-in-classmethod
tomoki10
1
800
genspark_presentation.pdf
haruki_uiru
0
150
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
7
63k
Azure Maps Visual in PowerBIで分析しよう
nakasho
0
190
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
220
企業が押さえるべきMCPの未来
takaakikakei
0
260
Aspire をカスタマイズしよう & Aspire 9.2
nenonaninu
0
360
MCPを理解する
yudai00
12
9.1k
Databricksで完全履修!オールインワンレイクハウスは実在した!
akuwano
0
140
白金鉱業Meetup_Vol.18_AIエージェント時代のUI/UX設計
brainpadpr
1
270
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
1.6k
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
33k
Rebuilding a faster, lazier Slack
samanthasiow
81
9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
690
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.7k
Documentation Writing (for coders)
carmenintech
70
4.7k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.5k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する