ふつうのJavaアプリ開発のための自動テスト戦略 / JJUG CCC 2018 Fall

JJUG CCC 2018 Spring #ccc_l1a

Transcript

1. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 1 ふつうのJavaアプリ開発のための 自動テスト戦略 JJUG CCC 2018 Fall #ccc_l1a Acroquest Technology株式会社 進藤 遼 (@shindo_ryo)
2. 自己紹介 • 進藤 遼 • Acroquest Technology株式会社 • アーキテクチャ考えたり コード書いたり • 前回のJJUG CCCではJUnit 5について話しました 後輩からは「またテストの話してる・・・」とか言われたよ！ • Twitter: @shindo_ryo Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2 『Java本格入門』発売中！
3. 今日話すこと • 開発者目線で考えた、より良い自動テストについて • 経験談を交えたテストコードの設計 今日話さないこと • QA目線での、テスト設計について （テストケースの作成など） • CIのベストプラクティス的なこと Copyright © Acroquest Technology Co., Ltd. All rights reserved. 3
4. 問題の背景 ◼ とある大規模なECサイトのバックエンド開発 • お客様のチームのほかに大きなベンダが数社 開発を担当している • 各APIがHTTPで相互に通信している - マイクロサービス的だが、そこまでマイクロでもない • Java 8 + Spring Boot - DBアクセスはMyBatisで、割と一般的なつくり • 開発の途中から参画 - 他ベンダが開発したモジュールの品質改善に取り組むことに Copyright © Acroquest Technology Co., Ltd. All rights reserved. 4
5. 問題の背景 構成図 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 5 Front API DB Cache Service API DB Cache Service API DB Cache Service
6. 何はともあれまずは テストを動かしてみよう！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 6
7. 問題の背景 大量に失敗するテスト Copyright © Acroquest Technology Co., Ltd. All rights reserved. 7
8. どうしてこうなった・・・ 実装者がローカルでテストしてるかどうかすら 怪しい（多分してない） テストの実行に時間がかかり過ぎる - 1時間以上かかるプロジェクトも存在した JenkinsでCIを動かしていたが、 テストが失敗しても放置 - -DskipTests=true ←やめろ！！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 8
9. 閑話休題 割れ窓理論 割れ窓理論とは、軽微な犯罪も徹底的に取り締まることで、凶悪 犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。「建 物の窓が壊れているのを放置すると、誰も注意を払っていないと いう象徴になり、やがて他の窓もまもなく全て壊される」との考 え方からこの名がある。(Wikipediaより) →壊れたテストを放置すると、「テストが失敗する」 ことへの警戒が下がってしまう Copyright © Acroquest Technology Co., Ltd. All rights reserved. 9
10. どこから手を付ければええねん！！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 10
11. 問題の整理 ◼ そもそもなぜテストを自動化するのか？ • リグレッションテストの工数を減らしたい - 簡単にテストを繰り返し実行したい • テストの再現性を高めたい - 誰がやっても同じテストになるように - 属人性の排除 • そして何よりフィードバックを高速化したい！ - プルリクごと、コミットごとに壊れていないかを確認 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 11
12. 問題の整理 ◼ よいテストコードとは スコープが整理されている - クラス名、パッケージ名、構造などからテスト対象、 スコープがわかる 環境依存が最小限 - 「Aさんの環境では動くのにBさんの環境では動かない」 で右往左往するのは時間のムダ テストの実行が速い - 速ければ速いほど、気軽にテストを実行できるようになる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 12
13. 自動テストは、効率的な開発サイクルを支え、 開発者への素早いフィードバックを可能にする Copyright © Acroquest Technology Co., Ltd. All rights reserved. 13 セットアップ 実装 テストコード作成 テスト実行 欠陥を早期に知る 修正 そのために自動テスト自体が高速で容易に 実行できるものになっていなければならない
14. テストをオールグリーン にすることは大事 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 14
15. それと同時に背景にある問題に 対処することも大事 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 15
16. テストコードの構造を見直す 脱・環境依存 テストの高速化 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 16 Step 1 Step 2 Step 3
17. Step 1: テストコードの構造を見直す Copyright © Acroquest Technology Co., Ltd. All rights reserved. 17
18. Step 1: 構造を見直す ◼ テストにはフェーズに応じたスコープがある • おそらく最も使われる分類が、単体テスト、結合テスト、 システムテスト、ユーザ受け入れテスト、etc… - 「単体」とは？クラス単体？API単体？ - プロジェクトで合意が取れていれば問題ないが、 往々にして認識がずれがち • Googleは「テストサイズ」という分類でスコープを定義し ている - S(small)テスト、M(medium)テスト、L(large)テスト Copyright © Acroquest Technology Co., Ltd. All rights reserved. 18
19. • テストサイズ by Google Step 1: 構造を見直す Sテスト Mテスト Lテスト ネットワークアクセス モック localhostのみ ◦ データベース モック ◦ ◦ ファイルアクセス モック ◦ ◦ 外部システム モック 非推奨 ◦ マルチスレッド × ◦ ◦ スリープ文 × ◦ ◦ システムプロパティ × ◦ ◦ 実行時間の上限 60秒 300秒 900秒以上 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 19 https://testing.googleblog.com/2010/12/test-sizes.html Sサイズテストでは モックを多用する
20. Step 1: 構造を見直す • レイヤーごとに役割を確認する Copyright © Acroquest Technology Co., Ltd. All rights reserved. 20 Controller Service Repository バリデーション JSONバインディング 業務ロジック DBアクセス（SQL） DB API
21. Step 1: 構造を見直す • Sサイズテストはレイヤごとの役割のテスト に集中する Copyright © Acroquest Technology Co., Ltd. All rights reserved. 21 Controller Service Repository DB @WebMvcTest POJOとしてテスト @MybatisTest
22. Step 1: 構造を見直す • Mサイズテストとして、 すべてのレイヤを結合 してテストする Copyright © Acroquest Technology Co., Ltd. All rights reserved. 22 Controller Service Repository DB API Request/Responseを 実際に投げてテスト (@SpringBootTest)
23. Step 2: 脱・環境依存 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 23
24. Step 2: 脱・環境依存 ◼ どれだけ手順を簡単にできるかを考える • 大抵変わらない設定はデフォルト値をセットしておく - DBの接続先など - 人によって変わるものは環境変数で切り替えられるようにする • セットアップが必要であればREADMEに収まる程度で - 長大なセットアップ手順書←読まれない&更新されないやつ • DBテストの環境をどうするかは悩ましい・・・ - 組み込みDB？外部DB？ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 24
25. Step 2: 脱・環境依存 利点 欠点 モック ・最も高速 ・SQLのテストができない 組み込みDB (H2, HSQL) ・起動が高速 ・再現性が低い (SQLの互換性など) 外部DB ・本番DBとほぼ同じ構成 の環境を使える ・環境依存になる ・複数人が同時にテスト すると更新が競合する ことがある Dockerコンテナ (ローカル) ・本番DBと同じプロダクト、 バージョンを使える ・Docker自体の問題に ハマる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 25 Dockerコンテナを選択
26. Step 3: テストの高速化 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 26
27. Step 3: テストの高速化 ◼ 問題点の確認 計測したところ、Springコンテナの起動時間が テスト実行時間の大部分を占めていた。 なおかつテストクラスごとにコンテナを 起動するようになっていた Springコンテナの１回の起動 ・・・ 30秒 Springコンテナを使っていたテストクラス ・・・ 200個 起動時間だけで30秒 × 200クラス ＝ 100分 テストの結果待ちでたくさんTwitterできるね！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 27
28. Step 3: テストの高速化 ◼ あとは地道に改善していく • 可能な限りテストクラスはフレームワークのサポート無しの POJOテストにする • Springコンテナの起動時間の短縮 • Springコンテナのキャッシュを有効にする 起動時間が20秒、起動回数が10回になれば・・・ 100分 ▶ 20秒 × 10回 ＝ 200秒 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 28
29. まとめ テストはオールグリーンにするだけではなくて 継続しやすい（=速い、簡単）なものにする 必要があるよ！ そのためにはテストコード自体の設計が大事だよ！ Java, Spring Bootでモダンな開発を やりたい仲間を募集しているよ！！（後づけ） Copyright © Acroquest Technology Co., Ltd. All rights reserved. 29
30. Evolve the Earth with Emotion of Technology Copyright © Acroquest Technology Co., Ltd. All rights reserved. 30 効果的な自動テストで開発効率↑↑