テストを書いた方が良いところ 書かなくても良いところ

CAMPHOR- DAY 2019のLT用資料です。

https://camphor.connpass.com/event/119434/

Transcript

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