Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

7f68f5f85f4a39df7d8d3c81cbbfb788?s=128

ぷらす

March 09, 2019
Tweet

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