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
650
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
4/16/25 - SFJug - Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
2
130
Winning at PHP in Production in 2025
beberlei
1
150
Рекомендации с нуля: как мы в Lamoda превратили главную страницу в ключевую точку входа для персонализированного шоппинга. Данил Комаров, Data Scientist, Lamoda Tech
lamodatech
0
790
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
190
AIエージェント開発手法と業務導入のプラクティス
ykosaka
8
2k
React ABC Questions
hirotomoyamada
0
540
PicoRabbit: a Tiny Presentation Device Powered by Ruby
harukasan
PRO
2
250
Terraform Cloudで始めるおひとりさまOrganizationsのすゝめ
handy
2
190
Web Intelligence and Visual Media Analytics
weblyzard
PRO
1
5.8k
アジャイル脅威モデリング#1(脅威モデリングナイト#8)
masakane55
3
230
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
130
グループ ポリシー再確認 (2)
murachiakira
0
110
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.1k
RailsConf 2023
tenderlove
30
1.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
4 Signs Your Business is Dying
shpigford
183
22k
Raft: Consensus for Rubyists
vanstee
137
6.9k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.8k
We Have a Design System, Now What?
morganepeng
52
7.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Automating Front-end Workflow
addyosmani
1369
200k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する