JSUG勉強会 2018年その2〜SpringとAPI時代の動く仕様への取り組み〜のメモ

はじめに

チラシの裏です。

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

一人目の寺島さんの発表資料↓
Springのプログラムモデルと動く仕様～テスト編～

• テストでは事前条件(give)・操作(when)・結果(then)で書く。
• SpockというGroovyで書かれたテストライブラリが便利。
• 自動テストは動く仕様という位置づけ。

事例：

1. テスト項目書が複雑でフラグ管理の手順が不明瞭。マニュアルでDBを操作してフラグを立てる？
2. テストメソッドからテスト内容を判別できない。
   ↓
   テストメソッド名をgive-when-thenにする。

カバレッジを満たすのがテストの目的ではない！
仕様レベルの話はコメントとして残し、本質ではない操作方法とかは明記しなくてもいい（隠蔽する）。
プロダクトコードからも仕様と関係ない部分は移譲する（Serviceクラスは業務処理に専念させるみたいな話？）。

DI containerにより、テスト観点以外の部分をstubやmockで解決できるようになった。

• Frameworkの親クラスの縛りからの開放
• 依存性の注入で依存関係を解決

テスト観点でない部分には、どんどんモックを導入する。

1. 状態中心のテスト　テスト前後でどう変わったか
2. 相互作用中心のテスト　どういうやり取りをしているか

モックに置き換えた部分は、別途テストを行い、最終的にモックに置き換えられないレベルまで階層を落とす。
当たり前だが、テスト観点のメソッドをモックにするのはNG!

E２Eテスト・シナリオテストから１つのメソッドのテストまで適用できる。
仕様の粒度には注意する必要がある。
テスト対象の使い方をテストするのが重要＝仕様をテストする。

粒度を書く際の注意として、XXフラグという表現はプログラマチックでビジネスとはかけ離れているので、ビジネスで使っている言葉を使う。

実際に社内でgive-when-thenで手動テストを書いてみた。

• テストを実行してエビデンスを取って最後にレビューをする。という流れから、事前にどういうテストを行うかレビューができたので、手戻りが減る。
• プログラマがテストを理解して進めるので、心理的安全。
• テストのやり方を変えたくらいでは、成果物の品質の差はない。
• ドキュメント作成のコスト増。

今後の展望
膨大な量の製品コードをどのようにテストするか。また品質保証するためには、リファクタリングでも高コスト。

• 散らばったテスト仕様を、一元管理したい。
• Spockの利用、E2Eの自動テストを活用した事例を作っていきたい。
• BDDやATDDなどアプローチはさておき、コードがリーダブルであることが大前提。

API時代の仮説検証開発の提言とツール ～API編～

↓二人目の音森さんの発表資料
API時代の仮説検証開発の提言とツール ～API編～

従来の開発：
序盤の「検討漏れや実装の段階で検証すると手戻りがある。仕様書や「コードのバージョン管理が必要

事例１：
半年設計・プロト、後に１年本開発。複数のベンダと連携が必要。
各ベンダで性質が異なる（設計書の有無・ソースを読めるかなど）。
APIを使う人と作る人で、どのレベルで疎通ができるかが大事。設計書、環境、ソース（環境：デプロイされてAPIを叩ける状態）。

ベンダが返却値を変更した場合、どのように連携するかが重要。
ベンダが提供する設計書と実際のソースに乖離がある場合も。

事例２：
対面で説明ができず、認識齟齬が起こる可能性。

そこで、仮説検証開発

• 要望が正しいか
• 仕様が正しいか
• 成果物が正しいか

仮説・入出力確認・仮実装・本開発を回す。
それぞれを検証するためのツール↓。

Swagger

粒度の齟齬を解決するにはSwaggerをつかうと実現できる。
作る側がSwagger editorでymlを記述するだけでAPIを叩ける。利用者がソースを見る必要がない。ただし、ソースとは連携していないのでソース変更があった場合はymlも修正が必要。

SpringFox

ソースコードから仕様書を生成できる。
APIを使う人に仕様書を見せればいいので認識齟齬が減る。
実際に叩けるかどうかは別問題。

Spring REST Docs

テストを実行すると成功したテストのドキュメントをAsciiDocに出力。Gradleでhtmlやpdfにもできるので、ドキュメントとソースの乖離をなくなる。
失敗したテストのドキュメントは出力されないので設計書の代わりになるわけではない。

結局はスピード感と粒度のバランスが重要。