Upgrade to Pro — share decks privately, control downloads, hide ads and more …

microservicesにおけるAPI自動テストにまつわるエトセトラ

 microservicesにおけるAPI自動テストにまつわるエトセトラ

18f39af6d18ccf70c9290df14bbe4221?s=128

Kunio Okita

March 07, 2017
Tweet

Transcript

  1. Copyright © DeNA Co.,Ltd. All Rights Reserved. Microservices における API⾃動テストに

    まつわるエトセトラ March 7, 2017 Kunio Okita (@okitan) SWET Group DeNA Co., Ltd.
  2. Copyright © DeNA Co.,Ltd. All Rights Reserved. ⾃⼰紹介 !  沖⽥

    邦夫 !  @okitan !  株式会社ディー・エヌ・エー !  SWETグループリーダー !  Selenium実践⼊⾨ !  みなさま第2刷も買ってください 2
  3. Copyright © DeNA Co.,Ltd. All Rights Reserved. SWETとは !  Software

    Engineer in Test の略 !  Google SETを参考にはじめて !  独⾃のVisionをもとに活動の幅を広げてきました !  活動の幅 !  SET !  TE (Test Engineer) !  SETI (Software Engineer, Tools and Infrastructure) の⼀部 !  かつての RE (Release Engineer) / BE (Build Engineer) もここの分類? 3
  4. Copyright © DeNA Co.,Ltd. All Rights Reserved. Microservices Architecture ! 

    いろいろ定義があると思いますが !  今⽇の話は RESTful な API サーバがたくさんある !  くらいのゆるふわ認識で⼤丈夫です 4
  5. Copyright © DeNA Co.,Ltd. All Rights Reserved. RESTful API開発のスタイル ! 

    リソース設計をしっかりする !  リソース定義をしっかり⾏い責務割当をきちんと設計する !  具体的にDeNAでやっているのは !  JSON Hyper Schema (2013版) で API specification を記述する !  要は JSON Schema draft4 に対応しているやつです !  OpenAPI specification (a.k.a swagger) でも基本同じです !  JSON Schema draft5以降は。。。 !  リソース設計のレビューはJSON Hyper Schemaに対して⾏う 5
  6. Copyright © DeNA Co.,Ltd. All Rights Reserved. RESTful APIのテスト ! 

    基本は各APIに対して !  開発者が開発しながらテストも開発 !  コンポーネントテスト !  コンポーネント統合テスト !  APIとしてHTTPで叩けるか !  他のAPIを叩きに⾏くところはstub !  システム統合テスト !  テスト環境にデプロイし、stubも基本使わない !  コンポーネント統合テストを流⽤可能 !  SWET(TE)によるテスト !  テスト対象をきちんと分析したテスト !  その他、APIのオーケストレーションによるシナリオテスト 6
  7. Copyright © DeNA Co.,Ltd. All Rights Reserved. SWETのRESTful APIのテスト ! 

    きちんとテスト対象分析して設計したテスト以外には !  例えばFuzzing !  JSON Schema と API テスト !  https://www.slideshare.net/naokishimizu/yapc-2014 !  現状やらなくなった !  その代わりJSON Schema⾃体のテストを推奨 7
  8. Copyright © DeNA Co.,Ltd. All Rights Reserved. SWETのRESTful APIのテスト ! 

    システム統合テストでのFuzzing !  JSON Schema と API テスト !  https://www.slideshare.net/naokishimizu/yapc-2014 !  やらなくなった理由 !  「システム統合テストならでは」のバグ検出数が少ない !  microservicesといっても実装が各APIでバラバラではなく !  ミドルウェア・フレームワークで⼀度対応していればOK !  検出されるバグのリスクが少ない 8
  9. Copyright © DeNA Co.,Ltd. All Rights Reserved. JSON Schema⾃体のテスト ! 

    Fuzzing で⾒つかった多くはJSON Schema⾃体の不備 !  意図通りschemaを記述できていない !  レビューだけでは担保できていなかった !  JSON Schemaを書くのと同時にJSON Schema⾃体のテストを書く !  あるJSONがvalidになるかinvalidになるか !  副次的な効果 !  書いたテストがサンプルになりわかりやすい !  TDDと同様にリソースデザインの助けになる 9
  10. Copyright © DeNA Co.,Ltd. All Rights Reserved. JSON Schema⾃体のテストのカバレッジ ! 

    コンポーネントテストでどれだけ担保できているかを測りたくなる !  スキーマ定義に対するテストとそのメトリクス !  http://qiita.com/okitan/items/a7cddc536755493b3452 !  記事中では静的解析的なアプローチでやっていたが !  C0(resourceのpropertyカバレッジ)あたりで限界を感じた !  やるなら動的解析かなと。。 10
  11. Copyright © DeNA Co.,Ltd. All Rights Reserved. JSON Schemaの静的解析 ! 

    コンポーネントテストだけだとFuzzingをやめる理由にはならない !  静的解析 !  JSONとしての正しさ !  $ref (別のオブジェクトへのリファレンス) が解決可能かのチェック !  property の typo がないかのチェック !  よくあったのが title が tilte になってる !  validationの不備 !  type: “string” なのに maxLength がないとか 11
  12. Copyright © DeNA Co.,Ltd. All Rights Reserved. ここまでのまとめ !  microservices

    でのAPI specificationに対して !  意図通りかけているかのテストを書く !  specificationに対して静的解析 !  システム統合テストレベルでやっていた⽋陥の検出をより早期に 12
  13. Copyright © DeNA Co.,Ltd. All Rights Reserved. API specificationの活⽤ ! 

    コード⽣成 !  JSON Schemaだと !  例えば Heroku 製 https://github.com/interagent !  heroics: HTTP Client for Ruby !  schematic: for Go !  committee: stub server (Rack Middleware) !  prmd: API Documentation !  pliny: code template !  OpenAPI specification !  swagger-codegen !  API Dashboard !  負荷試験スクリプト(JMeter)も可能 13
  14. Copyright © DeNA Co.,Ltd. All Rights Reserved. API specificationのSWETでの活⽤ ! 

    JSON Schemaからのコード⽣成 !  ⾃前で実装。。 !  HTTP Client !  stub サーバを内包 !  API Dashboard !  テストコード⽣成 !  RESTのセマンティクスを利⽤ !  負荷試験スクリプト⽣成 (Gatling) !  Gatling⽤HTTP Clientも⽣成 !  ⾃動⽣成に⾜りない情報はJSON Schemaを独⾃拡張 !  例: OpenAPI Specificationでいうところの Security Schema !  ドメインに特化した仮定を置いているので公開できない 14
  15. Copyright © DeNA Co.,Ltd. All Rights Reserved. API specificationからのテスト⽣成 ! 

    浅いテスト対象分析程度のテスト⽣成 !  最⼩限のパラメータセットで !  最⼩限+個別パラメータのセットで !  最⼤限のパラメータセットで !  (外部仕様からわかる)境界値試験 !  権限が⾜りない場合 !  validationがきちんと動いているか !  JSON Schemaの単体テストによりvalidation⾃体は保証されている前提 !  競合テスト !  簡単なシナリオテスト !  これにプラスしてテスト対象分析をきちんとした⾃動テストを⼿動作成 !  ただし、リリース後リグレッションテストとしてメンテするかは別 15
  16. Copyright © DeNA Co.,Ltd. All Rights Reserved. API specificationからのテスト⽣成の課題 ! 

    かなりドメイン限定の拡張や前提があり汎⽤的には使えない !  リソースの依存関係 !  OpenAPI specification v3 (3/1にrc0が出た) !  Callback Object !  簡単なシナリオ的なテストの⽣成に利⽤できる 16
  17. Copyright © DeNA Co.,Ltd. All Rights Reserved. API specificationからのテスト⽣成の課題 ! 

    API⾃動テストのデータ駆動化 !  現状 RSpec のコードを⽣成している !  テストフレームワークや実装⾔語⾮依存の形式で出⼒したい !  特にいろんな実装でテストスイートを共有できる !  データの追加だけでよくなるので開発者にもとっつきやすくなる !  なぜこれまでデータ駆動をやらなかったのか !  リソースの依存関係を汎⽤的に書く⽅法がなかった(知らない) !  これもCallback Objectで解決するとは思う !  UML Testing Profile 2.0って関係あるのかな !  よくしらない 17
  18. Copyright © DeNA Co.,Ltd. All Rights Reserved. まとめ !  microservices

    でのAPI specificationに対して !  意図通りかけているかのテストを書く !  specificationに対して静的解析 !  API specificationを活⽤し !  テストも⾃動⽣成できるよ !  今後の展望 !  OpenAPI specification v3 に移⾏していきたい⽅向? 18