闯补惫补のテスト骋谤辞辞惫测て?いいのて?はないかという话
- 2. もくじ ? 背景 ? はじめに ? テストに求められること ? Java × JUnitのテスト ? Groovy × Spockのテスト ? Groovyの活用 ? まとめ
- 3. 背景 ? Groovy、Spockについて ? いきなり勧めてもメリットが分かりにくい ? 導入するにあたって ? 使い方やメリットを共有したい ? 参考資料が欲しい
- 4. 注意点 ? このスライド ? テスト = ユニットテスト、テストコード ? プロダクションコードはJavaで開発を想 定
- 5. はじめに
- 6. テスト书いてますか？
- 8. 今回はもう一歩先の话
- 9. テストに求められること ? 仕様、処理の明確化 ? 複雑な仕様も簡潔な記述で理解できる ? テスト側にバグが生まれるような複雑な構造にしない ? 安全なコード修正、バグの検知 ? 開発スピードの向上 ? 開発者の安心感
- 11. 现実
- 12. テストに求められること (现実) ? 仕様、処理の明確化 ? 複雑なセットアップ、大量のモック化、読み取れない処理内容 ? 安全なコード修正、バグの検知 ? テスト成功させるためだけのその場限りの修正 ? 開発スピードの向上 ? 工数軽減のためにテスト自体を後回し ? 開発者の安心感 ? 不足したテスト、信頼性の低下による拭い去れない不安
- 13. 现実は厳しい
- 14. テストどうする?
- 16. よくある闯鲍苍颈迟
- 17. よくある闯鲍苍颈迟 テスト名が適当 繰り返されるsetupとassert - 途中で失敗すると実行されない - どこまでが初期化でどこまでが ターゲット? - 全ての組み合わせがわかりくい JUnit4からはassetThatが追加 一つのテストで複数メソッド のテスト
- 18. 闯鲍苍颈迟で解决
- 20. JUnit 5ではより改善? ? @DisplayNameでテスト名を記述 ? @Nestedのよる構造化 ? ParameterResolverでパラメータ化テスト ? DynamicTestによる動的テスト ? Rule、TestRunnerとかは廃止 ? Matcherに非依存 ? Java 8以上
- 21. 解决＼(镑辞镑)／
- 22. さらにテストが増えると…
- 23. うーん…
- 24. 本当に解决?
- 25. 実際に開発は もっと複雑
- 26. JUnitの問題点 ? 構造化すると可読性が悪化しやすい ? テストの失敗が分かりにくい ? 複雑になってくると記法の一貫性確保が難しい ? assertやmockなどが外部ライブラリに依存 ? そもそも、Javaは基本的に冗長
- 28. 闯补惫补なのに骋谤辞辞惫测?
- 29. Groovyとは ? ポストJava(置き換え)ではなく、Javaの拡張 ? Javaとの併用のために生まれ、併用に特化された 言語 ? モダンな言語の機能を積極的に取り込み ? Rubyに似た文法で柔軟、拡張性が高い ? Java VMとgroovy-all.jarだけあれば動く
- 30. Hello World
- 34. JavaエンジニアにとってのGroovy ? Groovyが分からなければJavaで書く ? 分かればGroovyも書く ? レビューなどを通してキャッチアップ ? 随時理解で十分なゆるい学習曲線
- 36. Spockとは? ? Groovyのテスティングフレームワーク ? PowerAssertによる強力なレポーティング ? ブロックによる記法の統一 ? DSLを使った簡潔で分かりやすい記述 ? 標準でMockのAPIを提供
- 39. 闯补惫补から骋谤辞辞惫测へ
- 41. Blocks ? ラベルによってブロック を分割 ? xUnit Test Patternsの "Four Phase Test"をフ レームワークとして強制 ＆宣言的に記述 ? 従わない場合エラー
- 42. Power Assert ? 失敗時に中間結果も含む詳 細を出力 ? Groovy本体にも取り込まれ た強力なレポーティング機 能 ? 多言語のライブラリにも移 植
- 43. Data Tables ? パラメータ化テストの サポート ? テストパターンの可読 性向上 ? ‘||’でパラメータと結果 を見分けやすく
- 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/
- 47. 多くのケース網羅が必要なテストにおいて 簡潔な記述 複雑な構造× Groovy × 厂辫辞肠办が解决
- 48. テストに便利なGroovy ? Collection ? Map Constructor ? GString ? File ? SQL ? DSL
- 49. Collection ? 容易な初期化 ? シンプルな記法 ? 蝉别迟耻辫などに便利
- 50. Map Constructor ? 1ラインで初期化 ? 蝉别迟耻辫で便利
- 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. Javaのかわりに Groovy
- 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