If user loads stubs from a directory, the order of the resources
is best left to the comparator by default. If the user wants to
order stubs explicitly, she now has to use ignoreExpectOrder(false)
(the default is true, unlike the normal mock mvc server).
without this change you could use only `artifactid` or `groupid:artifactid`
without this change when a stub is not found a null was returned
with this change you can use `groupid:artifactid:version` or `groupid:artifactid:version:classifier`
with this change when a stub is not found an exception is thrown
fixes#102
It turns out the WireMock does not (I think) contain a comparator
that helps. We have made a custom comparator that helps a bit
(it orders requests with the same URL in reverse order of the
number of headers matched).
Wrapping the WireMock matcher in a Hamcrest matcher, and also
using WireMock's native support for sorting mappings, so the
most specific match comes first.
without this change when the user adds context-path it gets ignored and WireMock fails to register stubs
with this change we update the WireMock instance to include the context path
fixes#99
without this change if one doesn't have spring integration java dsl on classpath and uses Stream the app will break on boot
with this change the wrong class on the conditional on class gets fixed
fixes#100
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
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
