Tweet
Tweet

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