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のテストGroovyでいいのではないかという話
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
disc99
September 11, 2016
Technology
350
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
JavaのテストGroovyでいいのではないかという話
disc99
September 11, 2016
More Decks by disc99
See All by disc99
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ
disc99
1
1.3k
アーキテクチャ選択の裏側
disc99
0
120
120リポジトリを1つのMonorepoに統合した理由
disc99
1
1.3k
モノリスとマイクロサービスを経てモジュラモノリスを導入した実践事例
disc99
25
15k
PaaS DX by Cloud Native Buildpacks
disc99
0
270
全てのAPIをProtocol Buffersで管理する / Manage all APIs with Protocol Buffers
disc99
2
5.8k
Serverless Application
disc99
1
3.2k
イベント駆動マイクロサービスアーキテクチャ / Event-Driven Microservices Architecture
disc99
4
3.1k
Event Sourcing 101
disc99
1
220
Other Decks in Technology
See All in Technology
MCP Appsを作ってみよう
iwamot
PRO
4
670
20260619 私の日常業務での生成 AI 活用
masaruogura
1
220
「エンジニア進化論」2028年の開発完全自動化、エンジニアはどう進化するか
cyberagentdevelopers
PRO
6
5.3k
就職⽀援サービスにおけるキャリアアドバイザーのシフトスケジューリング
recruitengineers
PRO
1
150
Disciplined Vibes: Scaling AI-Assisted Engineering
sheharyar
0
150
AIの性能が向上しても未解決な組織の重大問題は何か?/An Unsolved Organizational Problem in the Age of AI
moriyuya
4
680
作って終わりにしない タイミーのセマンティックレイヤー育成の現在地
chanyou0311
4
2.4k
いまさら聞けない「仕様駆動開発入門」 〜AI活用時代の開発プロセスを考える〜
findy_eventslides
2
140
新しいVibe Codingと”自走”について
watany
6
330
中期計画、2回作ってみた ~業務委託と正社員、両方の視点から~
demaecan
1
910
FinOps × AIエージェントで実現する コストインシデントの自動調査
oasis1994liveforever
0
150
2026TECHFRESH畢業分享會 - Lightning Talk - 打造精準高效的 MCP 設計模式與測試實務
line_developers_tw
PRO
0
1.1k
Featured
See All Featured
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
250
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
230
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
160
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
For a Future-Friendly Web
brad_frost
183
10k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
200
A better future with KSS
kneath
240
18k
The SEO identity crisis: Don't let AI make you average
varn
0
490
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
200
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
360
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.1k
Abbi's Birthday
coloredviolet
2
8.1k
Transcript
JavaのテストGroovy でいいのではないかと いう話 @disc99
もくじ • 背景 • はじめに • テストに求められること • Java ×
JUnitのテスト • Groovy × Spockのテスト • Groovyの活用 • まとめ
背景 • Groovy、Spockについて • いきなり勧めてもメリットが分かりにくい • 導入するにあたって • 使い方やメリットを共有したい •
参考資料が欲しい
注意点 • このスライド • テスト = ユニットテスト、テストコード • プロダクションコードはJavaで開発を想 定
はじめに
テスト書いてますか?
テストがどうあるべきか分か りますか?
今回はもう一歩先の話
テストに求められること • 仕様、処理の明確化 • 複雑な仕様も簡潔な記述で理解できる • テスト側にバグが生まれるような複雑な構造にしない • 安全なコード修正、バグの検知 •
開発スピードの向上 • 開発者の安心感
多くのケース網羅が必要なテストにおいて 簡潔な記述 複雑な構造×
現実
テストに求められること (現実) • 仕様、処理の明確化 • 複雑なセットアップ、大量のモック化、読み取れない処理内容 • 安全なコード修正、バグの検知 • テスト成功させるためだけのその場限りの修正
• 開発スピードの向上 • 工数軽減のためにテスト自体を後回し • 開発者の安心感 • 不足したテスト、信頼性の低下による拭い去れない不安
現実は厳しい
テストどうする?
Java × JUnit で解決する
よくあるJUnit
よくあるJUnit テスト名が適当 繰り返されるsetupとassert - 途中で失敗すると実行されない - どこまでが初期化でどこまでが ターゲット? - 全ての組み合わせがわかりくい
JUnit4からはassetThatが追加 一つのテストで複数メソッド のテスト
JUnitで解決
JUnitで解決 適切なテスト名 @Beforeによるsetup Theoriesでパラメータ化テスト コンテキスト単位でEnclosedなども使用 テストパターンの可読性向上 assertが一つになりテスト内容が明確化
JUnit 5ではより改善? • @DisplayNameでテスト名を記述 • @Nestedのよる構造化 • ParameterResolverでパラメータ化テスト • DynamicTestによる動的テスト
• Rule、TestRunnerとかは廃止 • Matcherに非依存 • Java 8以上
解決\(^o^)/
さらにテストが増えると…
うーん…
本当に解決?
実際に開発は もっと複雑
JUnitの問題点 • 構造化すると可読性が悪化しやすい • テストの失敗が分かりにくい • 複雑になってくると記法の一貫性確保が難しい • assertやmockなどが外部ライブラリに依存 •
そもそも、Javaは基本的に冗長
Groovy × Spock で解決する
JavaなのにGroovy?
Groovyとは • ポストJava(置き換え)ではなく、Javaの拡張 • Javaとの併用のために生まれ、併用に特化された 言語 • モダンな言語の機能を積極的に取り込み • Rubyに似た文法で柔軟、拡張性が高い
• Java VMとgroovy-all.jarだけあれば動く
Hello World
Hello World 違いは拡張子のみ
Javaの記法は ほぼそのまま動く (ラムダ式はクロージャ)
Groovyでよりシンプルに Groovyで書いた同じ処理 HTTPに限れば Javaで書いた処理
JavaエンジニアにとってのGroovy • Groovyが分からなければJavaで書く • 分かればGroovyも書く • レビューなどを通してキャッチアップ • 随時理解で十分なゆるい学習曲線
他言語を導入するのとの違い 知らない ちょっと知って る すごく知ってる 他言語 × △? ◎ Groovy
◯ ◯ ◎
Spockとは? • Groovyのテスティングフレームワーク • PowerAssertによる強力なレポーティング • ブロックによる記法の統一 • DSLを使った簡潔で分かりやすい記述 •
標準でMockのAPIを提供
JUnitからSpockへ(Before)
JUnitからSpockへ(After)
JavaからGroovyへ
JavaからGroovyへ Method Unrolling Blocks Power Assert Data Tables
Blocks • ラベルによってブロック を分割 • xUnit Test Patternsの "Four Phase
Test"をフ レームワークとして強制 &宣言的に記述 • 従わない場合エラー
Power Assert • 失敗時に中間結果も含む詳 細を出力 • Groovy本体にも取り込まれ た強力なレポーティング機 能 •
多言語のライブラリにも移 植
Data Tables • パラメータ化テストの サポート • テストパターンの可読 性向上 • ‘||’でパラメータと結果
を見分けやすく
Method Unrolling 実行時テスト名を動的に変更 文字列のメソッド
Others • Exception Test • Data Pipe • Mock •
Spy • Stub • @ExtensionAnnotation • 詳しくは • http://spock-framework-reference-documentation- ja.readthedocs.io/ja/latest/index.html • http://spockframework.github.io/spock/docs/1.0/
Java×JUnit to Groovy×Spock
多くのケース網羅が必要なテストにおいて 簡潔な記述 複雑な構造× Groovy × Spockが解決
テストに便利なGroovy • Collection • Map Constructor • GString • File
• SQL • DSL
Collection • 容易な初期化 • シンプルな記法 • setupなどに便利
Map Constructor • 1ラインで初期化 • setupで便利
GString • ヒアドキュメント • 可読性向上 • whereブロック変数との 組み合わせ可能 • モックやSQL文などに便
利
File • 簡潔な記述 • 外部ライブラリならCSV やExcelも扱いやすい • テストデータ生成に便利
SQL • 面倒なセットアップ無し • 外部ライブラリ不要 • テストデータ準備、 assertなどに便利
DSL • Javaでは出来ない言語 拡張 • アイディア次第で色々 可能(やり過ぎ注意) • 可読性、効率向上 https://github.com/disc99/table-setup
その他Groovy活用 • Geb • Groovyの機能を活用したSeleniumラッパー • Selenumも推奨するPageObjectパターンを利用したメンテナンス性の高いテスト、 JQueryライクなインターフェイス、Spock連携 • Gradle
• Spring、Hibernate、Androidなどにも標準採用されているビルドツール • Mavenのようなライフサイクル管理、依存性解決、Groovyのシンプルなシンタックス、 DSLを利用した可読性、柔軟なビルドスクリプト • IntelliJ IDEA • 標準でGroovyをサポートしているIDE。プラグインなどの追加不要でGroovyを記述可能
ただGroovyってどうなの? • 最近流行りのJVM言語ではない? • モダンな動的言語、テスト用途としては十分な機能 • 破壊的変更がある他のJVM言語とは違い、ほとんどのJava構文が使え る • 将来性は?
• 少なくともこの先数年は現役で使える(個人的印象) • 廃れたとしても、削減した時間で十分もとは取れる • それでも不安なら、Groovyの独自記法は避けJavaらしい記法によせる
テストに求められること (Groovy×Spock適用後) • 仕様、処理の明確化 → 複雑なセットアップ、多数のモック化、読み取れない処理内 容 • Groovyのシンプルなシンタックスによりテスト内容に集中可能 •
安全なコード修正、バグの検知 → その場限り、テスト成功させるためだけの修正 • PowerAssertによる失敗内容の明確化 • 開発スピードの向上 → 工数軽減のために後回し • 軽量化した記述量、可読性向上によって短時間でテスト記述が可能 • 開発者の安心感 → 不足したテストによる消し去れない不安 • whereブロックによるパラメータ化テストなど多くのケースを簡単に網羅可能
まとめ • Groovyは導入の負荷にならない学習コスト、緩やか な学習曲線 • Javaの冗長なテスト記述を軽減、高速化、可読性向上 • Spockで宣言的かつシンプルに多くのパターンを網羅 • PowerAssertでテスト失敗時にも直感的なエラー表示
• その他Groovy機能、ツールを利用し開発効率化
Javaのかわりに Groovy
Javaで開発するから Groovy
JavaのテストGroovyでいい んじゃない?
参考 • http://qiita.com/euno7/items/ 1e834d3d58da3e659f92 • http://www.slideshare.net/nobeans/javagroovy • http://qiita.com/kazurof/items/ 584a3ff49e9a2f4c7717 •
http://www.slideshare.net/uehaj/groovy- bootcamp-2015-by-jggug