始めに

最近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

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-06-24 (金) 20:26:35 (49d)