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
420
テスト”ケース”駆動開発 で手戻りをなくそう
Kawahara Ryoma
September 17, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
Efficient zero-copy networking using io_uring
ennael
PRO
0
330
コード✕AIーソフトウェア開発者のための生成AI実践入門~
yuhattor
3
720
エムスリー全チーム紹介資料 / Introduction of M3 All Teams
m3_engineering
1
280
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
810
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
13k
DenoでもViteしたい!インポートパスのエイリアスを指定してラクラクアプリ開発
bengo4com
1
1.9k
Develop to Survive - YAPC::Hakodate 2024 Keynote
moznion
8
2.1k
15 JSON serializers for Ruby
okuramasafumi
2
100
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
460
Low Latency Join Method for Distributed DBMS
yugabytejapan
0
160
テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜
ysknsid25
11
3.1k
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
How STYLIGHT went responsive
nonsquared
95
5.1k
BBQ
matthewcrist
85
9.2k
Designing with Data
zakiwarfel
98
5.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
Designing for Performance
lara
604
68k
Ruby is Unlike a Banana
tanoku
96
11k
The Language of Interfaces
destraynor
154
24k
Testing 201, or: Great Expectations
jmmastey
38
7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
25
660
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.5k
How to Think Like a Performance Engineer
csswizardry
16
1k
Transcript
テスト”ケース”駆動開発 で手戻りをなくそう
自己紹介 - 川原遼馬 (@ryohma0510) - 株式会社DeNA 2020年入社 - Rails/Golang/GCP -
今はRailsをGolangにリプレイスするプロジェクト - Keyball44ユーザー
どうすれば効率よく開発できるか
手戻りを少なくしたい
最初にテストケースを洗い出そう
エッジケースが一番手戻りを発生させる - エッジケースは設計に影響を与えやすい - エッジケースは最後に気づきやすい
テストケース駆動で、低コストでエッジケースに気づく ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後にプログラミング
こんな経験はありませんか? レビューで指摘されたエッジケースの対応のために、 コードをほぼ全て書き直す
こういうのはコードを書き終わった後に気づく 普段は少ないリクエスト数だけど、ある日だけ10倍になる 普通はバッチ処理失敗しないけど、失敗した時は途中から再実行したい 廃止された機能の過去データでのみ発生する状態がある
じゃあ最初に設計がっつりやればいいやん
書いてからしか気付けない
書いてから気づく vs 書いてしまうと修正が大変
結論:最初にテストケースを洗い出そう ロジックを箇条書きで整理する テストケースを箇条書きで整理する 簡単に図を書く テストケースを箇条書きで整理する 関数を用意してコメントだけ書く テストケースを箇条書きで整理する 最後に実装する