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
20251007: What happens when multi-agent systems become larger? (CyberAgent, Inc)
ornew
1
290
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
140
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
3
1.8k
20251014_Pythonを実務で徹底的に使いこなした話
ippei0923
0
200
WEBサービスを成り立たせるAWSサービス
takano0131
0
110
CoRL 2025 Survey
harukiabe
1
200
このままAIが発展するだけでAGI達成可能な理由
frievea
0
100
ガバメントクラウドの概要と自治体事例(名古屋市)
techniczna
3
240
OAuthからOIDCへ ― 認可の仕組みが認証に拡張されるまで
yamatai1212
0
120
Git in Team
kawaguti
PRO
3
370
Codexとも仲良く。CodeRabbit CLIの紹介
moongift
PRO
0
210
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
2
620
Featured
See All Featured
How to Ace a Technical Interview
jacobian
280
24k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
8
910
Speed Design
sergeychernyshev
32
1.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
33
2.3k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
35
6.1k
Building an army of robots
kneath
306
46k
Being A Developer After 40
akosma
91
590k
The Cost Of JavaScript in 2023
addyosmani
55
9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する