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

テストを書いた方が良いところ書かなくても良いところ 2019/3/9 CAMPHOR- DAY 2019 京都大学岸直輝

テストコード書いてますか？　

自己紹介 • 岸直輝 (@plus_kyoto) • 京都大学工学部電気電子工学科 2回生
• サーバーサイドの人 (GolangとかPythonとか) • インターンでJava書いてる @ 東京

Q. 何のためにテストを書く？

A. 正しく動作するか確認するため

でもたくさんテストを書く時間がないよ　

どこの部分をテストしたらいいか分からない　

大事なこと動作をきちんと確認したいところからテストを書いていく

例えば

DBアクセス ☑ CRUDが正しく動作しているか？ ☑ 正しいSQLが発行できているか? (JOIN etc.) モックに差し替えられがちで上のレイヤーのテストでバグが発見されにくい RepositoryとかDAOとか言う部分

認証周りサインインやサインアップ処理セキュリティチェックは大事！ ☑ バリデーションチェックされているか？ ☑ 権限に応じたパーミッションが設定されているか？

例外処理正常系よりも異常系の方が複雑になりがち ☑ 0やnull時の挙動はチェックしたか?(ヌルポ) ☑ 内部エラーとレスポンスが一致しているか？

逆に書かなくてもいいこともある

ライブラリのラッパー • 有名なOSSなどはしっかりテストが書かれている • 単にライブラリのAPIを呼ぶだけのコードをテストする意味はないテストの重複は時間の無駄

複数から呼ばれる単純な処理 • コード = 仕様レベルの単純な処理 • バグってても、呼び出し元のテストが落ちるのでバグ検出可能ただし、複雑な処理の場合は
原因切り分けのために、テストを書いた方が良さげ

まとめ

まとめ • モック化される部分のテストは書こう • ないがしろにしがちな例外処理はきちんと確認しよう • テストを書かなくてもいい部分があると認識しようテストを書いてバグにハマらない快適なコーディング生活を

Thank you Twitter : @plus_kyoto GitHub : naoki-kishi

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

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

ぷらす

More Decks by ぷらす

Other Decks in Technology

Featured

Transcript