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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 • 進藤遼 • Acroquest Technology株式会社 • アーキテクチャ考えたりコード書いたり • 前回のJJUG CCCではJUnit 5について話しました後輩からは「またテストの話してる・・・」とか言われたよ！ • Twitter: @shindo_ryo Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2 『Java本格入門』発売中！

Slide 3

Slide 3 text

Slide 4

Slide 4 text

問題の背景 ◼ とある大規模なECサイトのバックエンド開発 • お客様のチームのほかに大きなベンダが数社開発を担当している • 各APIがHTTPで相互に通信している - マイクロサービス的だが、そこまでマイクロでもない • Java 8 + Spring Boot - DBアクセスはMyBatisで、割と一般的なつくり • 開発の途中から参画 - 他ベンダが開発したモジュールの品質改善に取り組むことに Copyright © Acroquest Technology Co., Ltd. All rights reserved. 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

どうしてこうなった・・・実装者がローカルでテストしてるかどうかすら怪しい（多分してない）テストの実行に時間がかかり過ぎる - 1時間以上かかるプロジェクトも存在した JenkinsでCIを動かしていたが、テストが失敗しても放置 - -DskipTests=true ←やめろ！！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 8

Slide 9

Slide 9 text

閑話休題割れ窓理論割れ窓理論とは、軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。(Wikipediaより) →壊れたテストを放置すると、「テストが失敗する」ことへの警戒が下がってしまう Copyright © Acroquest Technology Co., Ltd. All rights reserved. 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

問題の整理 ◼ そもそもなぜテストを自動化するのか？ • リグレッションテストの工数を減らしたい - 簡単にテストを繰り返し実行したい • テストの再現性を高めたい - 誰がやっても同じテストになるように - 属人性の排除 • そして何よりフィードバックを高速化したい！ - プルリクごと、コミットごとに壊れていないかを確認 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 11

Slide 12

Slide 12 text

問題の整理 ◼ よいテストコードとはスコープが整理されている - クラス名、パッケージ名、構造などからテスト対象、スコープがわかる環境依存が最小限 - 「Aさんの環境では動くのにBさんの環境では動かない」で右往左往するのは時間のムダテストの実行が速い - 速ければ速いほど、気軽にテストを実行できるようになる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Step 1: 構造を見直す ◼ テストにはフェーズに応じたスコープがある • おそらく最も使われる分類が、単体テスト、結合テスト、システムテスト、ユーザ受け入れテスト、etc… - 「単体」とは？クラス単体？API単体？ - プロジェクトで合意が取れていれば問題ないが、往々にして認識がずれがち • Googleは「テストサイズ」という分類でスコープを定義している - S(small)テスト、M(medium)テスト、L(large)テスト Copyright © Acroquest Technology Co., Ltd. All rights reserved. 18

Slide 19

Slide 19 text

• テストサイズ 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サイズテストではモックを多用する

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Step 2: 脱・環境依存 ◼ どれだけ手順を簡単にできるかを考える • 大抵変わらない設定はデフォルト値をセットしておく - DBの接続先など - 人によって変わるものは環境変数で切り替えられるようにする • セットアップが必要であればREADMEに収まる程度で - 長大なセットアップ手順書←読まれない&更新されないやつ • DBテストの環境をどうするかは悩ましい・・・ - 組み込みDB？外部DB？ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 24

Slide 25

Slide 25 text

Step 2: 脱・環境依存利点欠点モック・最も高速・SQLのテストができない組み込みDB (H2, HSQL) ・起動が高速・再現性が低い (SQLの互換性など) 外部DB ・本番DBとほぼ同じ構成の環境を使える・環境依存になる・複数人が同時にテストすると更新が競合することがある Dockerコンテナ (ローカル) ・本番DBと同じプロダクト、バージョンを使える・Docker自体の問題にハマる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 25 Dockerコンテナを選択

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Step 3: テストの高速化 ◼ 問題点の確認計測したところ、Springコンテナの起動時間がテスト実行時間の大部分を占めていた。なおかつテストクラスごとにコンテナを起動するようになっていた Springコンテナの１回の起動・・・ 30秒 Springコンテナを使っていたテストクラス・・・ 200個起動時間だけで30秒 × 200クラス＝ 100分テストの結果待ちでたくさんTwitterできるね！ Copyright © Acroquest Technology Co., Ltd. All rights reserved. 27

Slide 28

Slide 28 text

Step 3: テストの高速化 ◼ あとは地道に改善していく • 可能な限りテストクラスはフレームワークのサポート無しの POJOテストにする • Springコンテナの起動時間の短縮 • Springコンテナのキャッシュを有効にする起動時間が20秒、起動回数が10回になれば・・・ 100分 ▶ 20秒 × 10回＝ 200秒 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text