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
560
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
2024年にチャレンジしたことを振り返るぞ
mitchan
0
150
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
300
Working as a Server-side Engineer at LY Corporation
lycorp_recruit_jp
0
350
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
230
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
550
DUSt3R, MASt3R, MASt3R-SfM にみる3D基盤モデル
spatial_ai_network
2
230
サーバーなしでWordPress運用、できますよ。
sogaoh
PRO
0
120
多様なメトリックとシステムの健全性維持
masaaki_k
0
110
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
euglena1215
9
3.2k
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
160
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
160
Yahoo! ズバトクにおけるフロントエンド開発
lycorptech_jp
PRO
0
100
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Typedesign – Prime Four
hannesfritz
40
2.4k
Done Done
chrislema
182
16k
Optimizing for Happiness
mojombo
376
70k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Embracing the Ebb and Flow
colly
84
4.5k
Writing Fast Ruby
sferik
628
61k
Side Projects
sachag
452
42k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
520
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
How STYLIGHT went responsive
nonsquared
96
5.2k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する