私は現在、 Postmanと呼ばれる優れた REST クライアントと連携して動作するオープンソースの API テスト スイートに取り組んでいます。
テスト スイートを使用して、一連の API 呼び出しを実行し、予期される JSON オブジェクト/配列 (またはその他のもの) に対する応答をチェックします。応答/期待値が動的であることを可能にしながら、2つを比較するための優れた構造を持っていると思います。
(口ひげのような) 構文で応答の動的部分を表すことができるようにすることで、動的部分を把握しました。基本的に、値がフォーマットされ{{content}}
ている場合、それに応じて処理されます。ここでの異なる値はNOT_NULL
、 、STRING
、ARRAY
、OBJECT
、およびNUMBER
です。
この関数の sudo コードは次のようになります。
function (response, expected) {
if expected has `{{}}` syntax {
switch syntax
check response type of against expected type of ({{type}})
set flag if failure
return
} else {
if response is the same type as expected {
switch based on type of response
case string
check if response/request are equal
set flag if failure
return
case array
check if response/request are equal
set flag if failure
return
case object
for key in object
call this function with response[key] and request[key]
} else {
set flag (failure)
return
}
}
}
これで問題なく動作すると思いますが、このチェッカーを思いついたときに見落としていた明らかな点がないか、またはこのかなり複雑なチェックをより効率的に行う方法があるかどうかを確認したかったのです。
前もって感謝します!
アップデート
sudo コードを調べたところ、期待した結果が得られない厄介なチェックが行われたようです。上記の関数は更新され、正常に動作するようになりました。