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
730
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
Introduction to Bill One Development Engineer
sansan33
PRO
0
300
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
260
AI-Readyを目指した非構造化データのメダリオンアーキテクチャ
r_miura
1
270
Claude Codeを駆使した初めてのiOSアプリ開発 ~ゼロから3週間でグローバルハッカソンで入賞するまで~
oikon48
10
5.3k
Introdução a Service Mesh usando o Istio
aeciopires
1
270
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3k
Findy Team+ QAチーム これからのチャレンジ!
findy_eventslides
0
490
生成AI時代のセキュアコーディングとDevSecOps
yuriemori
0
150
WEBサービスを成り立たせるAWSサービス
takano0131
1
200
AIフル活用で挑む!空間アプリ開発のリアル
taat
0
130
フレームワークを意識させないワークショップづくり
keigosuda
0
230
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
232
18k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
Automating Front-end Workflow
addyosmani
1371
200k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Designing for humans not robots
tammielis
254
26k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Gamification - CAS2011
davidbonilla
81
5.5k
A better future with KSS
kneath
239
18k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
990
Building an army of robots
kneath
306
46k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Making Projects Easy
brettharned
120
6.4k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する