Slide 1
Slide 1 text
テストを書いた方が良いところ
書かなくても良いところ
2019/3/9 CAMPHOR- DAY 2019
京都大学 岸 直輝
Slide 2
Slide 2 text
テストコード書いてますか？
Slide 3
Slide 3 text
自己紹介
● 岸 直輝 (@plus_kyoto)
● 京都大学 工学部 電気電子工学科 2回生
● サーバーサイドの人 (GolangとかPythonとか)
● インターンでJava書いてる @ 東京
Slide 4
Slide 4 text
Q. 何のためにテストを書く？
Slide 5
Slide 5 text
A. 正しく動作するか確認するため
Slide 6
Slide 6 text
でもたくさんテストを
書く時間がないよ
Slide 7
Slide 7 text
どこの部分をテストしたら
いいか分からない
Slide 8
Slide 8 text
大事なこと
動作をきちんと確認したい
ところからテストを書いていく
Slide 9
Slide 9 text
例えば
Slide 10
Slide 10 text
DBアクセス
☑ CRUDが正しく動作しているか？
☑ 正しいSQLが発行できているか? (JOIN etc.)
モックに差し替えられがちで
上のレイヤーのテストでバグが発見されにくい
RepositoryとかDAOとか言う部分
Slide 11
Slide 11 text
認証周り
サインインやサインアップ処理
セキュリティチェックは大事！
☑ バリデーションチェックされているか？
☑ 権限に応じたパーミッションが設定されているか？
Slide 12
Slide 12 text
例外処理
正常系よりも異常系の方が複雑になりがち
☑ 0やnull時の挙動 はチェックしたか?(ヌルポ)
☑ 内部エラーとレスポンスが一致しているか？
Slide 13
Slide 13 text
逆に書かなくてもいいこともある
Slide 14
Slide 14 text
ライブラリのラッパー
● 有名なOSSなどはしっかりテストが書かれている
● 単にライブラリのAPIを呼ぶだけのコードを
テストする意味はない
テストの重複は時間の無駄
Slide 15
Slide 15 text
複数から呼ばれる単純な処理
● コード = 仕様 レベルの単純な処理
● バグってても、呼び出し元のテストが
落ちるのでバグ検出可能
ただし、複雑な処理の場合は
原因切り分けのために、テストを書いた方が良さげ
Slide 16
Slide 16 text
まとめ
Slide 17
Slide 17 text
まとめ
● モック化される部分のテストは書こう
● ないがしろにしがちな例外処理はきちんと確認しよう
● テストを書かなくてもいい部分があると認識しよう
テストを書いてバグにハマらない
快適なコーディング生活を
Slide 18
Slide 18 text
Thank you
Twitter : @plus_kyoto
GitHub : naoki-kishi