Springのプログラムモデルと動く仕様～テスト編～

JSUG Springのプログラムモデルと動く仕様～テスト編～株式会社ビッグツリーテクノロジー＆コンサルティング SI事業部アーキテクチャG 寺島秀樹 #jsug

2 Copyright © 2018 Bigtree Technology&Consulting Ltd. All Rights Reserved.
• 設計？ • 仕様？ • ドキュメント？はじめに筆者は「設計とは“考えること”であり、アウトプットはその一側面である」と考えている

1. 物事をする方法。しかた。やりかた。「まだほかに仕様があるだろう」 2. 機械類や建築物などの構造や内容。「仕様の一部を変更する」仕様とは？ https://dictionary.goo.ne.jp/jn/107319/meaning/m0u/ デジタル大辞泉の解説

「ユーザの要求を満たすためにサービスやシステム、機能などがどのように振る舞うかを定めたもの」と定義するこの場での「仕様」の定義

寺島秀樹（@terahide27） (株)ビッグツリーテクノロジ＆コンサルティング所属 SIerを中心にアーキテクト・アジャイルコンサルタントとして就業システムの保守運用から営業支援まで手広くいろいろやってます CSP/CSPO/CSM TOCfE国際認定ファシリテータ/ アニメ/酒/ラーメン/ 自己紹介

• テスト駆動開発の話 • アジャイルの話 • すごい話今日しない話

• 実際の事例 • テストと仕様とプログラムの話 • 現場で試してみようと思ってる話（ちょっとだけ）今日する話

出来事

• 某サービスを運用している現場 • ５週程度のイテレーションでリリースを繰り返している • 保守を行うチームメンバは12人程度(ほとんどが経験３年目までの若いメンバ) • 自分はインフラのおもりや障害などの調査を中心にしていて、開発のイテレーションにはあまり関わってなかった背景

「手が足りないからステージング環境でテストしてください」「かしこま〜」ある日

テスト仕様書「ユーザの区分がxxで商材のなんたらフラグとなんたらフラグが立っている時になんたら画面でなんたらするとほにゃららがほにゃららで...」「？」ユーザの区分がxxなのはわかった。（それ以外のユーザではどうなるか書いてないけど一旦おいておこう）「商材のなんたらフラグってどうやって立てるんですか？ DB書き換えてええのん？」「ステージング環境でそんなことしないでください」「だったらどうやってその状態にするんですか？」（結構マニアックな機能だった）

Untestable Test Case

• テストしたい観点は書かれていた • それをテストするための状態にするにはどうすればいいかが書かれていなかったなにが問題だったか？

• 操作やその結果に対してはみなさんよく気づく • その操作を行う事前の条件や状態を忘れがち • e.g. エアコンの設定温度を20度にすると冷たい風がでる。本当？事前条件を表す？

• given 事前条件・状態 • when 対象に対する操作をした時 • then どうなるかテンプレート [given]の状態で[when]をすると[then] given - when – then

まさに仕様

この人ご存知？ http://www.startrek.com/database_article/spock

• JUnitみたいなもん • given - when - then でテストが書ける素晴らしいもの e.g. Spock def test(){ given: "カートにアイテムがある" 商品一覧を開く() カートにいれるby商品ID(1) when: "カートを開く" 商品一覧でカートリンクをクリックする() then: カート画面が表示されている() and: 購入ボタンがクリッカブルである() }

プログラマはプログラムを書くのが仕事我々はプログラマである https://www.lifehacker.jp/2014/12/141210programmer_signs.html

プログラムで表現することができればドキュメントと違い動かして検証をすることが容易自動テストを書けば繰り返しの検証もできる自動テストもまたプログラム自動テストのプログラムは、もはやテストが目的ではなく、「動く仕様」としての位置づけを求められる自動テストは動く仕様である

出来事

@Test public void test_success1(){…} @Test public void test_success2(){…} 延々と続く・・・前みたJUnit

@Test public void test(){ load(“xxxData.xls”); actual = sut(); assertWithExcel(actual, “expected.xlsx”); } 前みたJUnit

仕様？

まずはテストメソッドの名前を given - when - then で書くことをしてみよう JUnitでは？ @Test public void カートにアイテムがある状態でカートを開くと購入可能である(){ //given 商品一覧でカートにいれるby商品ID(1); //when 商品一覧でカートリンクをクリックする(); //then カート画面が表示されている(); 購入ボタンがクリッカブルである(); }

もう少しUnit Testみたいな例 @Test public void 商品がある状態でカートに追加すると購入可能である(){ //given assertThat(itemService.findAll().size(), graterThan(0)); //when Item item = itemService.findById(1); cartService.add(item); //then assertThat(cartService.isPurchasable(), is(true)); }

テストで確認したい部分が仕様レベルの話それをどう実現するか（指定がないならば）の話は隠蔽しても構わないむしろプログラムレベルの話（前述の例ならばDOMの操作など）は積極的に隠蔽した方がいい仕様レベルとそれ以外のレベル @Test public void カートにアイテムがある状態でカートを開くと購入可能である(){ //given // 商品一覧ページを開きIDが商品IDの親のtrタグの中の // classがaddCartのリンクをクリックする（プログラムレベルの話）商品一覧でカートにいれるby商品ID(1); //when // 「カートを開く」とあるが、開き方の指定はなし（操作レベルの話）商品一覧でカートリンクをクリックする(); //then カート画面が表示されている(); 購入ボタンがクリッカブルである(); }

仕様レベルの話を残しそれ以外は他所に委譲する結果テストのしやすさにつながってくる e.g. プロダクションコードにおける仕様と構造 public CartService{ //購入可能な状態で購入するとカートからアイテムがなくなり購入処理を行う public void purchase(){ if( ! this.isPurchasable()){ throw new IllegalStateException("is not purchasable"); } List<Item> items = this.findAll(); items.stream() .map(i -> toPurchased(i)) .forEach(p -> purchaseService.purchase(p))); this.deleteAll(items); } ・・・

つづき // カートにアイテムがあるならば購買処理の購買可能判定を行う public boolean isPurchasable(){ if( this.findAll().isEmpty() ){ return false; } return purchaseService.isPurchasable(); } public List<Item> findAll(){ return cartRepository.findAll(); } public void deleteAll(List<Item> items){ cartRepository.deleteAll(items); } private PurchasedItem toPurchased(Item item){ //snip 商品の特性によってなにやら難しい処理 }

Spring

Spring Ecosystem http://springtutorials.com/

DI Container

自動テストの際にテスト観点以外の依存した部分をMock やStubなどに差し替えることがやりやすくなった • Frameworkなどの親クラスみたいな縛りから解放された • 依存関係があった場合でも依存性の注入という形で解決される DI Container がもたらしたもの

前述の例ホワイトボックステスト //購入可能な状態で購入するとカートからアイテムがなくなり購入処理を行う if( ! this.isPurchasable()){ //モックにしてtrue or false を返す throw new IllegalStateException("is not purchasable"); } List<Item> items = this.findAll(); //モックにしてアイテムを２個返す items.stream() .map(i -> toPurchased(i)) // 複雑なことをしていてテストしづらいなら // モックに変えてシンプルにする .forEach(p -> purchaseService.purchase(p))); //モックにして // 2度呼ばれたことを検証する this.deleteAll(items); //モックにして呼ばれたことを検証する

状態中心のテストテストしたい対象の処理前後での状態の変化を検証することでテストを行う相互作用中心のテストテストしたい対象のオブジェクトの相互作用（メッセージのやりとり）を検証することでテストを行う平たく言うとどのメソッドがどのように何回呼び出されるか状態中心のテストと相互作用中心のテスト

依存部分はモックに変えていくことでテスト観点（仕様）にフォーカスしたテストになるモックに変えた部分はそれぞれ「仕様」があるはずなのでそれは個別にテストを行う最終的には依存しないテスト対象はモックに変えずにテストを行うのでホワイトボックステストとしては充分となる（前述の例だと repository や toPurchased() がその例）相互作用中心のテスト（私見）

前述の例再掲：ホワイトボックステスト //購入可能な状態で購入するとカートからアイテムがなくなり購入処理を行う if( ! this.isPurchasable()){ //モックにしてtrue or false を返す throw new IllegalStateException("is not purchasable"); } List<Item> items = this.findAll(); //モックにしてアイテムを２個返す items.stream() .map(i -> toPurchased(i)) // 複雑なことをしていてテストしづらいなら // モックに変えてシンプルにする .forEach(p -> purchaseService.purchase(p))); //モックにして // 2度呼ばれたことを検証する this.deleteAll(items); //モックにして呼ばれたことを検証する

E2Eのテストやもっと広いシナリオテストのように粒度の大きい話しから１つのメソッドに対しての粒度の小さい話しのいずれでも今日の話しは適用できるただし、仕様の粒度を間違えるとぐちゃぐちゃになるので要注意（特に粒度の小さい部分）今日の仕様の話は・・・

粒度の大小に関係なく、テスト対象の使い方をテストする（仕様をテストする）使い方をテストする・・・

e.g. • 北緯なん度、経度なん度の場所に向かいエレベータで何階に行き鍵を取り出しドアを開け靴を脱ぎ冷蔵庫から缶ビールを取り出してベッドに横になる粒度の違い

• プログラマはプログラム書くときの言葉に慣れすぎている • 最初に話したテスト仕様書の話しはすごくビジネスから遠い用語で書かれていた • 特に粒度の小さいテストの場合は要注意ＸXフラグみたいなもの

• ビジネスで使っている言葉で表現しましょう • 難しかったらせめて対象となるものの操作方法（画面とか）で表現しましょう • ただ抽象度の低いホワイトボックステストだとこれも難しいコツ

課題と今後

テスト仕様書はgiven-when-thenのテストで書くようにした結果 • トータルコストは下がった（手戻りが減った） • プログラマの心理的安全が高まった課題 • メンバによって理解度のバラツキが大きい • 品質は大差ない • テスト工数があがった実際にやってみた（自プロジェクト）

Sound only 自動テストに対する取り組み

テスト仕様としていろいろなところに散らばった仕様を一元管理してトレース可能に今考えてること

• spockを使って自動テストを記載するプロジェクトがちらほらと増えてきた • E2Eの自動テストをうまく活用しているプロジェクト • 今後は社内外で今日のような話を通して増やしていく予定会社としての取り組み

まとめ

• given - when - then • 仕様はビジネスで使う用語で表わそう • 粒度に気をつけて表わそう • プログラムは構造に気をつけよう • 積極的に自動テストに落とそうまとめ

最後に

• ドキュメンテーションや口伝だとうまく伝わらないものをどう伝えるかは永遠にテーマだと思う • BDD,ATDDのように検証の方向からのアプローチしたりDDDのように設計・実装からアプローチしたりいろいろな方向から取り組んでいくべき課題と捉えている • なにはともあれプログラムはリーダブルであることが大前提だと自分は思う • アプローチの一環として今までにはないサービスや開発形態が今後どんどんでてくるだろうからそういう面でも注目したいと思っている所感

ってことで API編へ

の前に 10分休憩

Springのプログラムモデルと動く仕様～テスト編～

Springのプログラムモデルと動く仕様～テスト編～

More Decks by terahide

Other Decks in Programming

Featured

Transcript