Slide 1
Slide 1 text
テスト”ケース”駆動開発
で手戻りをなくそう
Slide 2
Slide 2 text
自己紹介
- 川原遼馬 (@ryohma0510)
- 株式会社DeNA 2020年入社
- Rails/Golang/GCP
- 今はRailsをGolangにリプレイスするプロジェクト
- Keyball44ユーザー
Slide 3
Slide 3 text
どうすれば効率よく開発できるか
Slide 4
Slide 4 text
手戻りを少なくしたい
Slide 5
Slide 5 text
最初にテストケースを洗い出そう
Slide 6
Slide 6 text
エッジケースが一番手戻りを発生させる
- エッジケースは設計に影響を与えやすい
- エッジケースは最後に気づきやすい
Slide 7
Slide 7 text
テストケース駆動で、低コストでエッジケースに気づく
ロジックを箇条書きで整理する
テストケースを箇条書きで整理する
簡単に図を書く
テストケースを箇条書きで整理する
関数を用意してコメントだけ書く
テストケースを箇条書きで整理する
最後にプログラミング
Slide 8
Slide 8 text
こんな経験はありませんか？
レビューで指摘されたエッジケースの対応のために、
コードをほぼ全て書き直す
Slide 9
Slide 9 text
こういうのはコードを書き終わった後に気づく
普段は少ないリクエスト数だけど、ある日だけ10倍になる
普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい
廃止された機能の過去データでのみ発生する状態がある
Slide 10
Slide 10 text
じゃあ最初に設計がっつりやればいいやん
Slide 11
Slide 11 text
書いてからしか気付けない
Slide 12
Slide 12 text
書いてから気づく vs 書いてしまうと修正が大変
Slide 13
Slide 13 text
結論：最初にテストケースを洗い出そう
ロジックを箇条書きで整理する
テストケースを箇条書きで整理する
簡単に図を書く
テストケースを箇条書きで整理する
関数を用意してコメントだけ書く
テストケースを箇条書きで整理する
最後に実装する