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
without this change if you have a DiscoveryClient bean it's used for delegation. For tests with Stub Runner actually we don't want to delegate. There is an option however to turn on this delegation
fixes#82
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
without this people can be surprised with the transitive dependencies being included in their project from stub jars.
We explain 3 different approaches to solving this issue.
Fixes#55
* 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
