Download as PDF, PPTX
JavaのテストGroovyでいいのではないかという話
- 1.
- 2. もくじ • 背景 • はじめに •テストに求められること • Java × JUnitのテスト • Groovy × Spockのテスト • Groovyの活用 • まとめ
- 3. 背景 • Groovy、Spockについて • いきなり勧めてもメリットが分かりにくい •導入するにあたって • 使い方やメリットを共有したい • 参考資料が欲しい
- 4. 注意点 • このスライド • テスト= ユニットテスト、テストコード • プロダクションコードはJavaで開発を想 定
- 5.
- 6.
- 7.
- 8.
- 9. テストに求められること • 仕様、処理の明確化 • 複雑な仕様も簡潔な記述で理解できる •テスト側にバグが生まれるような複雑な構造にしない • 安全なコード修正、バグの検知 • 開発スピードの向上 • 開発者の安心感
- 10.
- 11.
- 12. テストに求められること (現実) • 仕様、処理の明確化 • 複雑なセットアップ、大量のモック化、読み取れない処理内容 •安全なコード修正、バグの検知 • テスト成功させるためだけのその場限りの修正 • 開発スピードの向上 • 工数軽減のためにテスト自体を後回し • 開発者の安心感 • 不足したテスト、信頼性の低下による拭い去れない不安
- 13.
- 14.
- 15.
- 16.
- 17. よくあるJUnit テスト名が適当 繰り返されるsetupとassert - 途中で失敗すると実行されない -どこまでが初期化でどこまでが ターゲット? - 全ての組み合わせがわかりくい JUnit4からはassetThatが追加 一つのテストで複数メソッド のテスト
- 18.
- 19.
- 20. JUnit 5ではより改善? • @DisplayNameでテスト名を記述 •@Nestedのよる構造化 • ParameterResolverでパラメータ化テスト • DynamicTestによる動的テスト • Rule、TestRunnerとかは廃止 • Matcherに非依存 • Java 8以上
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. JUnitの問題点 • 構造化すると可読性が悪化しやすい • テストの失敗が分かりにくい •複雑になってくると記法の一貫性確保が難しい • assertやmockなどが外部ライブラリに依存 • そもそも、Javaは基本的に冗長
- 27.
- 28.
- 29. Groovyとは • ポストJava(置き換え)ではなく、Javaの拡張 • Javaとの併用のために生まれ、併用に特化された 言語 •モダンな言語の機能を積極的に取り込み • Rubyに似た文法で柔軟、拡張性が高い • Java VMとgroovy-all.jarだけあれば動く
- 30.
- 31.
- 32.
- 33.
- 34. JavaエンジニアにとってのGroovy • Groovyが分からなければJavaで書く • 分かればGroovyも書く •レビューなどを通してキャッチアップ • 随時理解で十分なゆるい学習曲線
- 35.
- 36. Spockとは? • Groovyのテスティングフレームワーク • PowerAssertによる強力なレポーティング •ブロックによる記法の統一 • DSLを使った簡潔で分かりやすい記述 • 標準でMockのAPIを提供
- 37.
- 38.
- 39.
- 40.
- 41. Blocks • ラベルによってブロック を分割 • xUnitTest Patternsの "Four Phase Test"をフ レームワークとして強制 ＆宣言的に記述 • 従わない場合エラー
- 42. Power Assert • 失敗時に中間結果も含む詳 細を出力 •Groovy本体にも取り込まれ た強力なレポーティング機 能 • 多言語のライブラリにも移 植
- 43. Data Tables • パラメータ化テストの サポート •テストパターンの可読 性向上 • ‘||’でパラメータと結果 を見分けやすく
- 44.
- 45. 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/
- 46.
- 47.
- 48. テストに便利なGroovy • Collection • MapConstructor • GString • File • SQL • DSL
- 49. Collection • 容易な初期化 • シンプルな記法 •setupなどに便利
- 50. Map Constructor • 1ラインで初期化 •setupで便利
- 51. GString • ヒアドキュメント • 可読性向上 •whereブロック変数との 組み合わせ可能 • モックやSQL文などに便 利
- 52. File • 簡潔な記述 • 外部ライブラリならCSV やExcelも扱いやすい •テストデータ生成に便利
- 53. SQL • 面倒なセットアップ無し • 外部ライブラリ不要 •テストデータ準備、 assertなどに便利
- 54. DSL • Javaでは出来ない言語 拡張 • アイディア次第で色々 可能(やり過ぎ注意) •可読性、効率向上 https://github.com/disc99/table-setup
- 55. その他Groovy活用 • Geb • Groovyの機能を活用したSeleniumラッパー •Selenumも推奨するPageObjectパターンを利用したメンテナンス性の高いテスト、 JQueryライクなインターフェイス、Spock連携 • Gradle • Spring、Hibernate、Androidなどにも標準採用されているビルドツール • Mavenのようなライフサイクル管理、依存性解決、Groovyのシンプルなシンタックス、 DSLを利用した可読性、柔軟なビルドスクリプト • IntelliJ IDEA • 標準でGroovyをサポートしているIDE。プラグインなどの追加不要でGroovyを記述可能
- 56. ただGroovyってどうなの? • 最近流行りのJVM言語ではない? • モダンな動的言語、テスト用途としては十分な機能 •破壊的変更がある他のJVM言語とは違い、ほとんどのJava構文が使え る • 将来性は? • 少なくともこの先数年は現役で使える(個人的印象) • 廃れたとしても、削減した時間で十分もとは取れる • それでも不安なら、Groovyの独自記法は避けJavaらしい記法によせる
- 57. テストに求められること (Groovy×Spock適用後) • 仕様、処理の明確化 →複雑なセットアップ、多数のモック化、読み取れない処理内 容 • Groovyのシンプルなシンタックスによりテスト内容に集中可能 • 安全なコード修正、バグの検知 → その場限り、テスト成功させるためだけの修正 • PowerAssertによる失敗内容の明確化 • 開発スピードの向上 → 工数軽減のために後回し • 軽量化した記述量、可読性向上によって短時間でテスト記述が可能 • 開発者の安心感 → 不足したテストによる消し去れない不安 • whereブロックによるパラメータ化テストなど多くのケースを簡単に網羅可能
- 58. まとめ • Groovyは導入の負荷にならない学習コスト、緩やか な学習曲線 • Javaの冗長なテスト記述を軽減、高速化、可読性向上 •Spockで宣言的かつシンプルに多くのパターンを網羅 • PowerAssertでテスト失敗時にも直感的なエラー表示 • その他Groovy機能、ツールを利用し開発効率化
- 59.
- 60.
- 61.
- 62. 参考 • 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