RestAssuredでのビジネスロジックの分離方法

Question

REST Webサービスがあります。これはJSONデータ表現で動作します。私は機能テストを提供したいと思います。私はRestAssured frameworkを使用する予定です。出力jsonの正確性をテストするための理解可能なメソッドを提供します。

例は、get("/method").then().assertThat().body("obj.field", equalTo(5));

しかし、一つの問題が発生する：JSON構造が変更される場合は、すべてのテストは、無効とします。たとえば、fieldの名前をfield2に変更する場合は、すべてのテストをfieldの出現で修正する必要があります。この問題は、Webページのテスト問題と非常によく似ています。ここでは、Web要素の存在を確認する必要があります。Pag​​e Objectパターンで導入されました。同様の解決策がREST APIのテスト用に存在するのでしょうか、それとも優雅なものにアドバイスできますか？

Answer 1

HTMLページの場合と同じように、変更の影響が少ないテストを書く方法の1つは、戦略を使用して評価したいターゲットを見つけることです。 Webページでは、祖先への依存を避けるために、XPathクエリ、CSSセレクタ、またはIDを直接使用します。

JSONでどうやったらいいですか？ さてあなたは、正規表現を使用することができますが、それは本当に厄介取得することができたり、JSONのクエリのようなXPathを使用することができます

http://goessner.net/articles/JsonPath/
http://defiantjs.com/

だからあなたの場合には、信頼性の高いテストを書くことは何についての詳細ですあなたがそれを行うために使用するフレームワークではなく評価します。

Answer 2

あなたの質問で与えられた例では、レスポンスオブジェクトの本体全体が検証され、その場合、脆弱なテストが作成される可能性があります。

REST-アシュアードがすでにJSON応答の特定の部分をテストするために必要なすべての機能を提供ように見えるしかし：

JSON example

JSON Advanced Examples

Using JSON Path

あなたもmap objectsすることができます例えば、検証や操作など、構築されたオブジェクトを使用して望むものを実行します。

詳細については、hereを参照してください。

Answer 3

REST API（特別な公開）の変更は、GUIよりも少なくなります。 APIの変更が導入されると、新しいバージョンでマークし、古いバージョンを壊さないようにする必要があります（ほとんどの場合）。テストを可能な限りシンプルにし、追加のパターンを導入することなく、いくつかの利点があります。簡単に放棄して新しいものを書くことができます。 Hihgerのテストフレームワークの複雑さは、高い保守コストを提供します。 REST-Assuredであれば、ResponseSpecificationを作成してアサーションで再利用することができます。