The converted body looks different when done via the String notation than it does when done via a map notation. When working with String body and when matchers are provided, even when all entries of a map / list got removed, the map / list itself remains. That leads to unnecessary creation of checks for empty collection. With this method we're checking if the JSON path matcher is related to array checking and we're trying to remove that trailing collection. All in all it's better to use the Groovy based notation for defining body...
fixes#391
without this change in the generated test when SpringCloudContractAssertions are used the compiler is picking an invalid type of Assertj Assertions.
with this change we're explicitly casting to the appropriate interface so that the SpringCloudContractAssertions methods are picked
fixes#381
without this change in the generated test when SpringCloudContractAssertions are used, we're casting the read element of the JSON to a Collection class whereas we should be casting to an Iterable.
fixes#381
without this change the `org.springframework.cloud.contract.verifier.assertion.SpringCloudContractAssertions.assertThat` was missing in Spock tests
with this change it is added and matchers work fine again
fixes#382
without this change when a contract contains a long value inside the body, then the code fails to compile since the provided number is assumed to be an integer.
with this change we're appending an L literal to that value for the compiler to assume that it's a long value.
without this change there's no way to change the default path of the path to the contracts when trying to execute the convert / generateTests task for another project
with this change we're setting properly the `spring.cloud.contract.verifier.contractsDirectory` for both tasks
fixes#338
without this change we're very strict in terms of the number of called send methods on the rabbittemplate
with this change we accept that the method could have been called more than once
fixes#332
without this change we're not mocking all necessary methods in connection factory. When someone used the rabbittemplate, accidentaly we mocked the proper method to return a mocked connection factory. When rabbitmq started using different version of the `newConnection` in all places where rabbittemplate was used the real connection factory was created.
with this change we're mocking all `newConnection` methods to return a mocked connection
fixes#303
without this change you can by mistake use the http headers in a messaging headers which will fail to work
with this change we're adding the messagingContentType() method that allows to properly set the content type
fixes#296
With contract like this
```
// output message of the contract
outputMessage {
// destination to which the output message will be sent
sentTo 'verifications'
// the body of the output message
body(
eligible: true
)
headers {
header("contentType", applicationJsonUtf8())
}
}
```
the generated test produces
```
ContractVerifierMessage response = contractVerifierMessaging.receive("verifications");
assertThat(response.getHeader("contentType")).isEqualTo("application/json;charset=UTF-8");
```
The headers in the response is a MimeType not a String so the equality check fails.
fixes#297
with the new layout of contracts and stubs the package name was improperly generated (for chars like +, or digits)
with this change we're converting those chars to _
fixes#276
without this change there's no option to use Stub Runner to pick stubs from classpath
with this change we're adding that option. It's enough for the user not to provide neither the `repositoryRoot` nor `workOffline`. If that's the case then Classpath scanning will take place.
fixes#282
without this change if the user has jsons that contain `.` in a key (e.g. `foo.bar.baz`) then the produced json path is wrong
with this change we're wrapping all keys in `[' ']` format (e.g. `['foo.bar.baz']`) so that the json path gets properly translated
fixes#269
