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
800
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
AIエージェント×GitHubで実現するQAナレッジの資産化と業務活用 / QA Knowledge as Assets with AI Agents & GitHub
tknw_hitsuji
0
130
ABEMAのバグバウンティの取り組み
kurochan
1
150
Phase10_組織浸透_データ活用
overflowinc
0
440
「通るまでRe-run」から卒業!落ちないテストを書く勘所
asumikam
2
430
DDD×仕様駆動で回す高品質開発のプロセス設計
littlehands
1
1.2k
A Casual Introduction to RISC-V
omasanori
0
510
GCASアップデート(202601-202603)
techniczna
0
240
Phase04_ターミナル基礎
overflowinc
0
640
頼れる Agentic AI を支える Datadog のオブザーバビリティ / Powering Reliable Agentic AI with Datadog Observability
aoto
PRO
0
240
会社紹介資料 / Sansan Company Profile
sansan33
PRO
16
410k
Visional 28新卒プロダクト職(エンジニア/デザイナー)向け 会社説明資料 / Visional Company Briefing for Newgrads 28
visional_engineering_and_design
1
110
Cortex Code CLI と一緒に進めるAgentic Data Engineering
__allllllllez__
0
550
Featured
See All Featured
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
260
Building Applications with DynamoDB
mza
96
7k
Mind Mapping
helmedeiros
PRO
1
130
Chasing Engaging Ingredients in Design
codingconduct
0
150
Designing Experiences People Love
moore
143
24k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.9k
Code Reviewing Like a Champion
maltzj
528
40k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.3k
Faster Mobile Websites
deanohume
310
31k
Automating Front-end Workflow
addyosmani
1370
200k
Utilizing Notion as your number one productivity tool
mfonobong
4
270
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
150
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する