without this change it's impossible to use Rest Assured 3.0 with Spring Cloud Contract. That's because we are adding Rest Assured 2.0 imports.
with this change we detect Rest Assured version. If 3.0 is available on the classpath we change the imports
fixes#266
The best situation is to provide fixed values but sometimes you need to reference a request in your response. In order to do this you can profit from the fromRequest() method that allows you to reference a bunch of elements from the HTTP request. You can use the following options:
- `fromRequest().url()` - return the request URL
- `fromRequest().query(String key)` - return the first query parameter with a given name
- `fromRequest().query(String key, int index)` - return the nth query parameter with a given name
- `fromRequest().header(String key)` - return the first header with a given name
- `fromRequest().header(String key, int index)` - return the nth header with a given name
- `fromRequest().body()` - return the full request body
- `fromRequest().body(String jsonPath)` - return the element from the request that matches the JSON Path
fixes#237
without this change the local repository maven setup is completely ignored
with this change whatever you have set up locally will be taken into consideration
without this it can be misunderstood that execute() can be used with Strings
with this we're informing the users that the value of the given property (url, header, body) has to be uniquely a execute command
fixes#231
without this change it's impossible to assert with response matchers all elements of an array
with this change we're using AssertJs conditions in case the pattern contains [*]
fixes#217
with this change all available stub converters on the classpath will be executed to convert the contract. That way you can make such a flow pass:
- from DSL input
- generate Java tests
- produce WireMock stubs
- produce Pact files
fixes#194
with this change we're providing support for Pact based contracts. No longer do you have to set up your contracts using the Groovy DSL. In the same way as with the DSL you can use the Pact contracts to generate tests and the stubs on the producer side.
fixes#96
Stub / Test Matchers (#186)
Without this change we're forcing users to embed their dynamic properties inside the body. For some this is natural and acceptable, but especially for the users coming from the Pact world this sounds bizarre. Also some other people have a problem with remembering who the consumer / producer is etc.
With this change we're introducing the stubMatchers and testMatchers section. Thanks to this one can separate the body from defining the dynamic properties. Especially for Pact users this is more natural. Speaking of which this is a prerequisite for #96fixes#185
Without this change we're forcing users to embed their dynamic properties inside the body. For some this is natural and acceptable, but especially for the users coming from the Pact world this sounds bizarre. Also some other people have a problem with remembering who the consumer / producer is etc.
With this change we're introducing the stubMatchers and testMatchers section. Thanks to this one can separate the body from defining the dynamic properties. Especially for Pact users this is more natural. Speaking of which this is a prerequisite for #96fixes#185
