Supporting request matchers in DSL about hoverfly-java

[mogronalol]

I think this looks good, but I don't think globMatcher should be inferred. I think behind the scenes we should have something like:

requestMatchers.globMatcher("/api/*")
requestMatchers.exactMatcher("/api")

Then in the DSL, the argument can only take:

public void foo(final Matcher matcher)
public void foo(final String string) // Creates a exactMatcher internally

We also need to make sure to limit what's possible for each part of a request. So making it impossible to pass a jsonPath matcher into the path part of a request.

[benjih]

Hey @tommysitu,

This is a nice proposal. Regarding number 7, Hoverfly works opposite to this. The absence of these fields means they are no checked. If you wanted to match a request with an empty body, you would need to specify the body, rather than leaving it out.

[tommysitu]

@benjih I was thinking if I write the following DSL:

service("www.test.com")
 .get("/api/foo)
.willReturn(success())

I would expect it to match a simple get request with no body or query params.

If my code has a bug which sends unexpected query parameters, then my test should fail. It means that I shouldn't need to have .queryParams(empty()) explicitly. It's the default settings.

If I want to match the requests with any query parameters, then I will set queryParams(any()) in the DSL.

This is not how Hoverfly works, but I think it works better in the DSL.

[tommysitu]

Released as v0.6.0