tec_tec_blog

いちSEの日々の興味のあるところを取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

JSUG勉強会 2018年その2 SpringとAPI時代の動く仕様への取り組みに参加してきました。

3月7日(水)に開催されたJSUGの勉強会に参加してきました。

jsug.doorkeeper.jp

いつものPivotalLabの会場いっぱいになるぐらいに参加人数も多く、盛況な状況でした。

スピーカの方がSpringの説明として「SpringはJavaエンタープライズ開発の屋台骨と化している(Springエコシステム)」と改めて説明されていて、ますまず学習する必要あると再認識しました。

以下、それぞれのセクションごとのメモです。

後半はちょっと体力的に電池切れ気味でした。。(自身知っていた内容でもあり、、)

 

動く仕様テスト編

www.slideshare.net

  • システム設計の謎を解くという本の筆者曰く、「設計とは”考えること”であり、アウトプットはその一側面である」
  • テスト仕様書だけでは、テストできない現場に遭遇
    • 事前フラグを立てる仕様をだれも知らなかった
  • 事前の状態、条件を表現することを忘れがち
  • 例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化が楽になった。
  • 状態中心のテストと、相互作用中心のテストという2種類がある
  • テスト対象のクラスのメソッドをMock化してよいの?という議論があった。スピーカーとしては、テストしたい観点がテストできていれば絶対NGという訳ではないと考える(三角測量的な観点)
  • 会話、整理する場合は、仕様の粒度があっているかを最初に確認することが大事
  • 仕様はビジネスで使う用語で表す
  • コミュニケーションは永遠の課題。アプローチや取りうる策は増えてきているので、今後もいろいろ検討していくべし!

 

API

www.slideshare.net

  • 従来の開発あるある
    • 試しに画面レイアウト作成ーイメージとちょっと違う。。
    • 設計書サンプルーユーザー属性が1つ抜けてる。。
    • 実装の都合上、設計を返させてくださいー検証環境で触ってみたい。。
      • バグ、要望の嵐。。
    • 序盤で漏れなく検討する必要がある
  • 実例プロジェクト
    • 複数ベンダのAPIと連携する
    • フロントとAPIの開発を実施
    • 性質の異なるAPI(設計書有無・検証環境有無、ソースコード読める・読めない)
  • 仮説検証型開発を適応
  • クライアント:早い段階で検証する:Swaggerを使う
  • ベンダ側での検証サイクルを回し続ける:SpringFox
    • Springのソースコードから仕様書を自動生成できる(CIで回すと便利)
  • ドキュメントの乖離をなくす:Spring Rest Docs
    • テストコードから設計書を作成する。成功したテストケースしか出力されない
    • テスト後にasciidocフォルダにドキュメントが吐かれる

WebAPIのところはエンプラでAWSとかも使いつつどのように一連の開発をしていくのかは、今後整理していきたいところですね。(流れも速いエリアですが、、)

 

運営の皆さん、スピーカーのお二方、ありがとうございました!!