JSUG勉強会 2018年その2 SpringとAPI時代の動く仕様への取り組みに参加してきました。
3月7日（水）に開催されたJSUGの勉強会に参加してきました。
いつものPivotalLabの会場いっぱいになるぐらいに参加人数も多く、盛況な状況でした。
スピーカの方がSpringの説明として「SpringはJavaのエンタープライズ開発の屋台骨と化している（Springエコシステム）」と改めて説明されていて、ますまず学習する必要あると再認識しました。
以下、それぞれのセクションごとのメモです。
後半はちょっと体力的に電池切れ気味でした。。（自身知っていた内容でもあり、、）
動く仕様テスト編
- システム設計の謎を解くという本の筆者曰く、「設計とは”考えること”であり、アウトプットはその一側面である」
- テスト仕様書だけでは、テストできない現場に遭遇
- 事前フラグを立てる仕様をだれも知らなかった
- 事前の状態、条件を表現することを忘れがち
- 例1：エアコンの設定温度を20度にすると冷たい風が出る。
- 例2：一覧画面からボタン押すと詳細画面に。0件の状態ならどうなるか？
- given-when-thenでテスト仕様を表現する。
- テンプレート：[given]の状態で[when]すると[then]となる
- SpockというJunitのようなものがある。（groovyのテストフレームワーク）
- given-when-thenでテストが書ける素晴らしいもの
- 自動テストは動く仕様である
- Junitではどうするか？まずはテストメソッド名をgiven-when-thenの形で書くことを始めるのが良い
- 例：カートにアイテムがある状態でカートを開くと購入可能である()というテストメソッド名にする。実装はgiven-when-thenを順番に記載していく。
- Spring FreamworはDIコンテナから生まれている。DIコンテナによりテスト時のMock,Stub化が楽になった。
- 状態中心のテストと、相互作用中心のテストという２種類がある
- テスト対象のクラスのメソッドをMock化してよいの？という議論があった。スピーカーとしては、テストしたい観点がテストできていれば絶対NGという訳ではないと考える（三角測量的な観点）
- 会話、整理する場合は、仕様の粒度があっているかを最初に確認することが大事
- 仕様はビジネスで使う用語で表す
- コミュニケーションは永遠の課題。アプローチや取りうる策は増えてきているので、今後もいろいろ検討していくべし！
API編
- 従来の開発あるある
- 試しに画面レイアウト作成ーイメージとちょっと違う。。
- 設計書サンプルーユーザー属性が1つ抜けてる。。
- 実装の都合上、設計を返させてくださいー検証環境で触ってみたい。。
- バグ、要望の嵐。。
- 序盤で漏れなく検討する必要がある
- 実例プロジェクト
- 仮説検証型開発を適応
- クライアント：早い段階で検証する：Swaggerを使う
- ベンダ側での検証サイクルを回し続ける：SpringFox
- Springのソースコードから仕様書を自動生成できる（CIで回すと便利）
- ドキュメントの乖離をなくす：Spring Rest Docs
- テストコードから設計書を作成する。成功したテストケースしか出力されない
- テスト後にasciidocフォルダにドキュメントが吐かれる
WebAPIのところはエンプラでAWSとかも使いつつどのように一連の開発をしていくのかは、今後整理していきたいところですね。（流れも速いエリアですが、、）
運営の皆さん、スピーカーのお二方、ありがとうございました！！
