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
780
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
次世代AIコーディング:OpenAI Codex の最新動向 進行スライド/nikkei-tech-talk-40
nikkei_engineer_recruiting
0
130
人工知能のための哲学塾 ニューロフィロソフィ篇 第零夜 「ニューロフィロソフィとは何か?」
miyayou
0
410
Redshift認可、アップデートでどう変わった?
handy
1
130
「駆動」って言葉、なんかカッコイイ_Mitz
comucal
PRO
0
140
会社紹介資料 / Sansan Company Profile
sansan33
PRO
11
390k
_第4回__AIxIoTビジネス共創ラボ紹介資料_20251203.pdf
iotcomjpadmin
0
180
迷わない!AI×MCP連携のリファレンスアーキテクチャ完全ガイド
cdataj
0
420
AI駆動開発ライフサイクル(AI-DLC)の始め方
ryansbcho79
0
320
AWS re:Invent 2025 を振り返る
kazzpapa3
2
110
「リリースファースト」の実感を届けるには 〜停滞するチームに変化を起こすアプローチ〜 #RSGT2026
kintotechdev
0
810
国井さんにPurview の話を聞く会
sophiakunii
1
360
コールドスタンバイ構成でCDは可能か
hiramax
0
130
Featured
See All Featured
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
32
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
130
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.5k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Speed Design
sergeychernyshev
33
1.5k
Everyday Curiosity
cassininazir
0
120
Google's AI Overviews - The New Search
badams
0
890
Agile that works and the tools we love
rasmusluckow
331
21k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.3k
GraphQLの誤解/rethinking-graphql
sonatard
74
11k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する