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
710
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
140
テストを軸にした生き残り術
kworkdev
PRO
0
200
La gouvernance territoriale des données grâce à la plateforme Terreze
bluehats
0
170
dbt開発 with Claude Codeのためのガードレール設計
10xinc
2
1.2k
S3アクセス制御の設計ポイント
tommy0124
3
200
職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~
daitasu
0
160
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
1
480
Webブラウザ向け動画配信プレイヤーの 大規模リプレイスから得た知見と学び
yud0uhu
0
230
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
160
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.2k
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
920
OCI Oracle Database Services新機能アップデート(2025/06-2025/08)
oracle4engineer
PRO
0
110
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Bash Introduction
62gerente
615
210k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Practical Orchestrator
shlominoach
190
11k
A designer walks into a library…
pauljervisheath
207
24k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
580
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Raft: Consensus for Rubyists
vanstee
140
7.1k
How GitHub (no longer) Works
holman
315
140k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する