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

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