postmanとopenapi
Top / postmanとopenapi始めに †
最近postmanをつかう現場が増えてきたように思う
curlコマンドでいいじゃないかとか思っていた。
結合テストで、メンバーが人力のテスト項目を作って、「ふーん、たいへんそうねぇ。がんばってね。」
とかおもってたら、案の定大変で、大人数が手伝わされる羽目になってしまった。
あー、あの時、自動化をするように、メンバーを説得できていたらなぁとしみじみ、おもってしまった。
そこで、寝る前にそのあたりの技術について考察を書いてから寝ようとおもってこの記事を書いている。
テスト項目エクセルに書くメリット、デメリット †
エクセルは汎用的なところがメリットだ。パソコンの知識が低レベルでも読める。
しかし、そこに書いてある内容をつかって打鍵しようとなると、間に人間が介在することになる、それがデメリットの根源だ。
もともと、API定義書にはテストに必要な情報を詰め込まれているのではないだろうか？
リクエストのパラメータだったり、レスポンスのパラメータだったりする。
API定義書とテスト仕様書のギャップについて考える †
API定義書は正常な予期されたデータ、テストは異常系の予期されていないデータを扱う。というざっくりとした分け方があるのではないかと仮定する。
たとえば、APIであるパラメータが数値であって範囲が指定されているとすると、テストでは、その指定されてない範囲外の場合というものもテスト仕様書で定義されるべきものになるという関係があるように思う。
自分が目指せそうなゴールを考えてみる †
テストケースの面について自動生成を考えてみる †
API定義書から、テストをすべて生成することは可能だろうか？
正常系のサンプルデータがあれば、正常系だけは生成できそうな気がする。 異常系はある程度のスケルトンはつくれそうだが、そこから先は手作業でいれないといけないのかもなぁ。
将来的にはAI補完させることができそうな気がする。 さらに、設計書をAIに読ませることができるようになれば、もっと生成できそうだ。
テストケースの自動生成の成果物 †
エクセル形式で出力したいか？
いや、自動的に実行できるのが良いと思う。
curlコマンドの提供をうけれる状態の場合について考える †
特殊な状況下ではあるが、バックエンドが別会社であり、openapi定義書とcurlコマンド の提供をうけれるとする。（今、自分がそういう状態なのだ
curlコマンドはopenapiの定義にかなり近いが、テストのために少しずれているものになっている。
このすこしのズレが、テストケースの本質のように思う。これを機械的に認識させることは可能であろうか？
curlコマンドのテストケース部分の自動認識についての考察 †
手順的には以下のものになるだろう
step1 openapiのパース
step2 curlコマンドのパース
step3 openapiのパース結果からcurlコマンドを予測
step4 step3の予測結果から、curlコマンドのパース結果の違いを抽出
step5 step4の違いから、テストの意図を認識させる
まてまて、curlコマンドもらえる今の状況について考える †
curlコマンドもらえるんなら、それをエクセルのテストケースにはりつけとけば いいじゃないか？
もしかして、いまの現場のメンバーは、もらったcurlコマンドをもとに、日本語風のテストケースを書いてテスターに渡して、そのテスターは、その日本語をもとにcurlコマンドつくったり、postman叩いたりしてるのか。。。？
なんか、諸悪の根源は、エクセルに日本語かかせたがる、
知識のないリーダ層に問題がありそうだな。
老害ということばもあるが、自分の経験上、文系の社内政治が得意なリーダが そのような害悪の根源になっている感じがする。
大企業のような組織が大きくなればなるほど、そういうのが多い。
きょうは、このへんにして寝るとする
postman †
公式ドキュメント †
https://learning.postman.com/docs/getting-started/introduction/
postman script †
https://learning.postman.com/docs/writing-scripts/script-references/test-examples/
リンク集 †
postmanにapi定義を読み込ませてテストする的な解説ページが結構あったのでリンクをはっておく
https://kageura.hatenadiary.jp/entry/postmancollection
https://qiita.com/yito-gxp/items/09787d9a98717e701d32
https://ren.nosuke.me/blog/202003/20200303/
postmanlabs †
postmanが提供しているライブラリとか
https://github.com/postmanlabs
postmanがopenapiのver3.1に対応した話 †
https://blog.postman.com/postman-now-supports-openapi-3-1/
これは、結構政治的な要素を含んだ話で、これまでopenapi3.0.1までは、
openapi-generatorが主導的だったようにおもう、しかしopenapi3.1.0からは、 schemeの構造がjson-schemeを採用するようになったのである。
openapi-generatorは、対応できていない段階で、openapi3.1.0がでてきた背景には、 postmanがjavascriptベースでつくられており、jsonでopenapi3.0.1のパースの実装が困難だったので、技術的な解決策ではなく政治的な解決策をとって、json-schemeでもイイヨネみたいない感じできめていったのだとおもう。
json-schemeのほうが、モデルの継承とかがまだ、十分対応できていない段階でそうなっており、openapiの定義としては、記述できる範囲がせばまった感じなのだ。
それよりかは、json-schemeのパーサーがつかえるほうがいいよね。的な方向に舵がとられたという感じだ、なので、javaでまだjson-schemeのパーサーって有力なものがないから、今後はpostmanがopenapiに準拠していくような流れになっていくのではないかとおもっている。
だれか、openapi-generatorのパーサーのメンテしてくれないかなぁ
その他のopenapi-generatorへの妨害と思われる箇所 †
実はopenapi-generatorのプロジェクトをパースしようとすると、コンパイルエラーになる状態になっており、だれかがいらないプルリクをまぜてしまったのだとおもう。
じぶんとしては、タイミング的に考えて、postman勢の政治的解決をしたがる人々による、故意によるものなのではないかとおもっている。
postmanの解説動画 †
https://www.youtube.com/watch?v=YRzpziA35Mg
パーサーの比較 †
OpenAPIParser †
openapi-generatorは、io.swagger.parser.OpenAPIParserをつかっています。
https://mvnrepository.com/artifact/io.swagger.parser.v3/swagger-parser
swagger-api/swagger-parser †
2022/06に、OAS3.1に対応
https://github.com/swagger-api/swagger-parser/releases/tag/v2.1.0
きになる技術 †
JsonスキーマをTSで出力 https://github.com/bcherny/json-schema-to-typescript
