the biggest problem was related with the scenario in which a jar with shared contracts is downloaded
with this change the output JAR structure is proper
fixes#156
When using contract plugins together with a shared repo with contracts we end up with creating contract tests for all the contracts. Stubs are created properly but tests generation ignores the path pattern.
With this change we fix the way tests are generated
fixes#155
with this change to DSL we're adding some helper methods and DSL simplifications
- c(...) / p(...) - for consumer / producer
- for regex - e.g. $(anyUrl()) - insead of $(consumer(regex(url()))
- Added helper headers and media types
- Added helper http methods
fixes#149
without this change it's impossible to execute any custom method to assert a response for a body that is just text
with this change you can do it
fixes#150
without this change for convention class names we haven't escaped illegal chars
with this change the illegal chars are escaped and no compilation issues occur
fixes#137
without this change only explicit Spring AMQP support was present
with this change support for spring-amqp annotated listener endpoints was added
fixes#127
without this change we couldn't alter the mapper
with this change you can customize the whole verifier objectmapper or the objectmapper that is on classpath
fixes#97
without this change the only way to ignore a contract was to provide it in the plugin's config
with this change you can also set it on the contract itself.
fixes#30
without this change when generating contract tests we were not iterating over a parsed json with test side values only. We had DslProperties that were ignored by multiple dispatch
with this change when generating tests we first convert the parsed json into its test side (those with `producer` method) and only then perform any logic
fixes#85
without this change the user was forced to use a single base class for all of the generated tests. It could become problematic after some time.
With this change we provide a range of options of providing different base classes for different contracts.
fixes#16
With this functionality you can have one centralized repository containing all contracts. This repo will have to produce a JAR containing all contracts. The layout of the repository can be arbitrary but some sensible defaults are assumed. The producer will be able to then download that JAR and produce tests and stubs from it.
fixes#38
* reorganized the entries (now the Contract details went to the very bottom)
* added FAQ section where versioning and dynamic props are better defined
* added in a couple of places links to Groovy JSON docs
fixes#69
