転載します。https：//www.jianshu.com/p/e3277824a10a
そして、ダミーサービスなど
春クラウド契約は何ですか？
春クラウド契約は、CDC（顧客主導契約）により、JVMベースのアプリケーションを開発するためのサポートを提供します。これは、TDD（テスト駆動開発）をテストするための新しい方法を提供する - ベースのインターフェース。
なぜテストを行うための契約を使うのか？
ただ、マイクロサービスアーキテクチャの使用を見て、呼び出しがあり、あなたの地域であればさまざまなサービス間の関係を、次のとおりです。
あなたは、サービス上の特定のフォーカスをテストしたい場合は、他のサービスは、彼らがテストすることができ、一緒にプレイしておく必要があります。また、統合テストをたくさん書き、外部サービス・コールのすべてがモックされています。
これらの2つの方法をテストするためのコストが高いです。それでは、どのようにこの問題を解決するには？
答えは：コンパクトテスト
-
アドバンテージ契約テストは
一度サービスとサービス間の契約を定義し、春の雲の契約は、ユーザーがサービスをテストするために、独自に焦点を当てることができるように、あなたはまた、統合テストの多くを記述する必要はありません、サービス消費者側のモックサーバスタブを提供します。
契約テスト -
契約該当するテストシナリオは、
サービスが実際に必要な契約テストを書いていない、あまりにも多くの外部コールを依存していない場合は、すべてのシーンのは、適用されます。場合にのみ、多くのサービスに依存しますが、特にシステムに依存して、契約のテストが適用されます。 -
コスト契約テストの
強み契約は、いずれかの契約上の上流と下流の間の契約の調印は、他の当事者が知っていることができるようになり、変更された後に、ということです。しかし、あなただけの一方的な契約テストを追加した場合、実際には、重要性は単にAPIドキュメントをテストするために、最高の状態で、素晴らしいではありません。
プロセスの使用では、複雑なビジネスシナリオがあるがある場合、私たちはしばしば、多くのデータので、モックする必要があるが、それはこの目的のために契約の多くを記述する必要があり、テストデータの準備に長い時間がかかります。
どのように契約を定義するには？
Spring Cloud Contract现在支持2种格式 yaml和groovy。
groovy灵活性比较高，但是上手成本有点高。
org.springframework.cloud.contract.spec.Contract.make {
request {
method 'PUT'
url '/api/12'
headers {
header 'Content-Type': 'application/vnd.org.springframework.cloud.contract.verifier.twitter-places-analyzer.v1+json'
}
body '''\
[{
"created_at": "Sat Jul 26 09:38:57 +0000 2014",
"id": 492967299297845248,
"id_str": "492967299297845248",
"text": "Gonna see you at Warsaw",
"place":
{
"attributes":{},
"bounding_box":
{
"coordinates":
[[
[-77.119759,38.791645],
[-76.909393,38.791645],
[-76.909393,38.995548],
[-77.119759,38.995548]
]],
"type":"Polygon"
},
"country":"United States",
"country_code":"US",
"full_name":"Washington, DC",
"id":"01fbe706f872cb32",
"name":"Washington",
"place_type":"city",
"url": "http://api.twitter.com/1/geo/id/01fbe706f872cb32.json"
}
}]
'''
}
response {
status OK()
}
}
yaml上手比较简单，但是，对于复杂的契约支持稍微弱一点。
description: Some description
name: some name
priority: 8
ignored: true
request:
url: /foo
queryParameters:
a: b
b: c
method: PUT
headers:
foo: bar
fooReq: baz
body:
foo: bar
matchers:
body:
- path: $.foo
type: by_regex
value: bar
headers:
- key: foo
regex: bar
response:
status: 200
headers:
foo2: bar
foo3: foo33
fooRes: baz
body:
foo2: bar
foo3: baz
nullValue: null
matchers:
body:
- path: $.foo2
type: by_regex
value: bar
- path: $.foo3
type: by_command
value: executeMe($it)
- path: $.nullValue
type: by_null
value: null
headers:
- key: foo2
regex: bar
- key: foo3
command: andMeToo($it)
我个人还是比较倾向于使用yaml，主要还是因为yaml语法比较简单，同时，对于90%的契约，其实都是简单型契约，很少会遇到复杂的使用场景，如果你要写一个特别复杂的契约，可能你就需要好好想想如何简化这个契约了。
契约只要组成部分就是 request（method，url，body，headers），response（status，body），我们比较常用的方式是 将request的body和response的body定义成2个json文件，然后，使用fromFile方法直接引用。
groovy 写法
import org.springframework.cloud.contract.spec.Contract
Contract.make {
request {
method('PUT')
headers {
contentType(applicationJson())
}
body(file("request.json"))
url("/1")
}
response {
status OK()
body(file("response.json"))
headers {
contentType(textPlain())
}
}
}
yaml写法
request:
method: GET
url: /foo
bodyFromFile: request.json
response:
status: 200
bodyFromFile: response.json
request.json
{ "status" : "REQUEST" } response.json
{ "status" : "RESPONSE" } 附上源码：https://github.com/huleTW/spring-contract-yaml-demo/tree/master