Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ふつうのJavaアプリ開発のための自動テスト戦略 / JJUG CCC 2018 Fall
Search
Ryo Shindo
December 14, 2018
Programming
9
5k
ふつうのJavaアプリ開発のための自動テスト戦略 / JJUG CCC 2018 Fall
JJUG CCC 2018 Spring #ccc_l1a
Ryo Shindo
December 14, 2018
Tweet
Share
More Decks by Ryo Shindo
See All by Ryo Shindo
今こそ知りたいSpring Test / Spring Fest 2020
rshindo
11
6.6k
こわくないソースコードリーディング生活 / JJUG CCC 2019 Fall
rshindo
15
9.6k
開発者のためのSpring Boot Actuator入門 / jsug-2019-08
rshindo
5
6.2k
早わかりSpring Data JDBC / jsug-2019-01
rshindo
5
4.3k
Spring WebFluxで学ぶReactive Application / Introduction to Reactive
rshindo
1
2.3k
まだまだ間に合う!JUnit 5入門 / JJUG CCC 2018 Spring
rshindo
6
3.4k
Spring Data JDBCを使い倒す! / Intruduction to Spring Data JDBC
rshindo
4
2.3k
Other Decks in Programming
See All in Programming
Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜
pvcresin
2
690
uniqueパッケージの内部実装を支えるweak pointerの話
magavel
0
920
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.3k
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1.2k
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
410
iOSアプリの信頼性を向上させる取り組み/ios-app-improve-reliability
shino8rayu9
0
150
『毎日の移動』を支えるGoバックエンド内製開発
yutautsugi
2
200
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
340
開発生産性を上げるための生成AI活用術
starfish719
1
180
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
600
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
680
GitHub Actions × AWS OIDC連携の仕組みと経緯を理解する
ota1022
0
240
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Optimizing for Happiness
mojombo
379
70k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
A better future with KSS
kneath
239
17k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Balancing Empowerment & Direction
lara
4
680
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
32
2.2k
Automating Front-end Workflow
addyosmani
1371
200k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Transcript
Copyright © Acroquest Technology Co., Ltd. All rights reserved. 1
ふつうのJavaアプリ開発のための 自動テスト戦略 JJUG CCC 2018 Fall #ccc_l1a Acroquest Technology株式会社 進藤 遼 (@shindo_ryo)
自己紹介 • 進藤 遼 • Acroquest Technology株式会社 • アーキテクチャ考えたり コード書いたり
• 前回のJJUG CCCではJUnit 5について話しました 後輩からは「またテストの話してる・・・」とか言われたよ! • Twitter: @shindo_ryo Copyright © Acroquest Technology Co., Ltd. All rights reserved. 2 『Java本格入門』発売中!
今日話すこと • 開発者目線で考えた、より良い自動テストについて • 経験談を交えたテストコードの設計 今日話さないこと • QA目線での、テスト設計について (テストケースの作成など) •
CIのベストプラクティス的なこと Copyright © Acroquest Technology Co., Ltd. All rights reserved. 3
問題の背景 ◼ とある大規模なECサイトのバックエンド開発 • お客様のチームのほかに大きなベンダが数社 開発を担当している • 各APIがHTTPで相互に通信している - マイクロサービス的だが、そこまでマイクロでもない
• Java 8 + Spring Boot - DBアクセスはMyBatisで、割と一般的なつくり • 開発の途中から参画 - 他ベンダが開発したモジュールの品質改善に取り組むことに Copyright © Acroquest Technology Co., Ltd. All rights reserved. 4
問題の背景 構成図 Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 5 Front API DB Cache Service API DB Cache Service API DB Cache Service
何はともあれまずは テストを動かしてみよう! Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 6
問題の背景 大量に失敗するテスト Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 7
どうしてこうなった・・・ 実装者がローカルでテストしてるかどうかすら 怪しい(多分してない) テストの実行に時間がかかり過ぎる - 1時間以上かかるプロジェクトも存在した JenkinsでCIを動かしていたが、 テストが失敗しても放置 - -DskipTests=true
←やめろ!! Copyright © Acroquest Technology Co., Ltd. All rights reserved. 8
閑話休題 割れ窓理論 割れ窓理論とは、軽微な犯罪も徹底的に取り締まることで、凶悪 犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。「建 物の窓が壊れているのを放置すると、誰も注意を払っていないと いう象徴になり、やがて他の窓もまもなく全て壊される」との考 え方からこの名がある。(Wikipediaより) →壊れたテストを放置すると、「テストが失敗する」 ことへの警戒が下がってしまう Copyright
© Acroquest Technology Co., Ltd. All rights reserved. 9
どこから手を付ければええねん!! Copyright © Acroquest Technology Co., Ltd. All rights reserved.
10
問題の整理 ◼ そもそもなぜテストを自動化するのか? • リグレッションテストの工数を減らしたい - 簡単にテストを繰り返し実行したい • テストの再現性を高めたい -
誰がやっても同じテストになるように - 属人性の排除 • そして何よりフィードバックを高速化したい! - プルリクごと、コミットごとに壊れていないかを確認 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 11
問題の整理 ◼ よいテストコードとは スコープが整理されている - クラス名、パッケージ名、構造などからテスト対象、 スコープがわかる 環境依存が最小限 - 「Aさんの環境では動くのにBさんの環境では動かない」
で右往左往するのは時間のムダ テストの実行が速い - 速ければ速いほど、気軽にテストを実行できるようになる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 12
自動テストは、効率的な開発サイクルを支え、 開発者への素早いフィードバックを可能にする Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 13 セットアップ 実装 テストコード作成 テスト実行 欠陥を早期に知る 修正 そのために自動テスト自体が高速で容易に 実行できるものになっていなければならない
テストをオールグリーン にすることは大事 Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 14
それと同時に背景にある問題に 対処することも大事 Copyright © Acroquest Technology Co., Ltd. All rights
reserved. 15
テストコードの構造を見直す 脱・環境依存 テストの高速化 Copyright © Acroquest Technology Co., Ltd. All
rights reserved. 16 Step 1 Step 2 Step 3
Step 1: テストコードの構造を見直す Copyright © Acroquest Technology Co., Ltd. All
rights reserved. 17
Step 1: 構造を見直す ◼ テストにはフェーズに応じたスコープがある • おそらく最も使われる分類が、単体テスト、結合テスト、 システムテスト、ユーザ受け入れテスト、etc… - 「単体」とは?クラス単体?API単体?
- プロジェクトで合意が取れていれば問題ないが、 往々にして認識がずれがち • Googleは「テストサイズ」という分類でスコープを定義し ている - S(small)テスト、M(medium)テスト、L(large)テスト Copyright © Acroquest Technology Co., Ltd. All rights reserved. 18
• テストサイズ 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サイズテストでは モックを多用する
Step 1: 構造を見直す • レイヤーごとに役割を確認する Copyright © Acroquest Technology Co.,
Ltd. All rights reserved. 20 Controller Service Repository バリデーション JSONバインディング 業務ロジック DBアクセス(SQL) DB API
Step 1: 構造を見直す • Sサイズテストはレイヤごとの役割のテスト に集中する Copyright © Acroquest Technology
Co., Ltd. All rights reserved. 21 Controller Service Repository DB @WebMvcTest POJOとしてテスト @MybatisTest
Step 1: 構造を見直す • Mサイズテストとして、 すべてのレイヤを結合 してテストする Copyright © Acroquest
Technology Co., Ltd. All rights reserved. 22 Controller Service Repository DB API Request/Responseを 実際に投げてテスト (@SpringBootTest)
Step 2: 脱・環境依存 Copyright © Acroquest Technology Co., Ltd. All
rights reserved. 23
Step 2: 脱・環境依存 ◼ どれだけ手順を簡単にできるかを考える • 大抵変わらない設定はデフォルト値をセットしておく - DBの接続先など -
人によって変わるものは環境変数で切り替えられるようにする • セットアップが必要であればREADMEに収まる程度で - 長大なセットアップ手順書←読まれない&更新されないやつ • DBテストの環境をどうするかは悩ましい・・・ - 組み込みDB?外部DB? Copyright © Acroquest Technology Co., Ltd. All rights reserved. 24
Step 2: 脱・環境依存 利点 欠点 モック ・最も高速 ・SQLのテストができない 組み込みDB (H2,
HSQL) ・起動が高速 ・再現性が低い (SQLの互換性など) 外部DB ・本番DBとほぼ同じ構成 の環境を使える ・環境依存になる ・複数人が同時にテスト すると更新が競合する ことがある Dockerコンテナ (ローカル) ・本番DBと同じプロダクト、 バージョンを使える ・Docker自体の問題に ハマる Copyright © Acroquest Technology Co., Ltd. All rights reserved. 25 Dockerコンテナを選択
Step 3: テストの高速化 Copyright © Acroquest Technology Co., Ltd. All
rights reserved. 26
Step 3: テストの高速化 ◼ 問題点の確認 計測したところ、Springコンテナの起動時間が テスト実行時間の大部分を占めていた。 なおかつテストクラスごとにコンテナを 起動するようになっていた Springコンテナの1回の起動
・・・ 30秒 Springコンテナを使っていたテストクラス ・・・ 200個 起動時間だけで30秒 × 200クラス = 100分 テストの結果待ちでたくさんTwitterできるね! Copyright © Acroquest Technology Co., Ltd. All rights reserved. 27
Step 3: テストの高速化 ◼ あとは地道に改善していく • 可能な限りテストクラスはフレームワークのサポート無しの POJOテストにする • Springコンテナの起動時間の短縮
• Springコンテナのキャッシュを有効にする 起動時間が20秒、起動回数が10回になれば・・・ 100分 ▶ 20秒 × 10回 = 200秒 Copyright © Acroquest Technology Co., Ltd. All rights reserved. 28
まとめ テストはオールグリーンにするだけではなくて 継続しやすい(=速い、簡単)なものにする 必要があるよ! そのためにはテストコード自体の設計が大事だよ! Java, Spring Bootでモダンな開発を やりたい仲間を募集しているよ!!(後づけ) Copyright
© Acroquest Technology Co., Ltd. All rights reserved. 29
Evolve the Earth with Emotion of Technology Copyright © Acroquest
Technology Co., Ltd. All rights reserved. 30 効果的な自動テストで開発効率↑↑