New verification type: FUNCTION

Currently there exist two verification types:

• PactVerification.REQUEST_RESPONSE – verifies an HTTP response from a request
• PactVerification.ANNOTATED_METHOD – can be used to verify either an HTTP response, or a message and metadata

I would like to propose a third verification type, PactVerification.FUNCTION, which would be similar to PactVerification.ANNOTATED_METHOD except that:

• only a single function is required, it would be a factory of String -> Any (but really, it would return specific types that the library already understands, like MessageAndMetadata).
• the function would be provided explicitly to ProviderVerifier instead of via scanning the classpath for annotated methods
• the function would not be invoked by reflection (e.g. java.lang.reflect.Method.invoke()), it would just be called normally like any other callback method in the ProviderVerifier. this means the method scope would be the same as any method in the test class instead of having to provide a specific instance for invocation.

This could be used for both messages and request/response, although the return types would need to vary depending on the interaction type. Probably the return value can be the same as the return values that are currently supported by the PactVerification.ANNOTATED_METHOD type.

My guess is the easiest way to implement this is to have another bifurcation in ProviderVerifier.verifyInteraction which would call a different method if the verification type is FUNCTION, for example verifyResponseByFunction, and define a new property on the ProviderVerifier that would contain the available function to call (verificationFunction: Function<String, Any>, or something like that). There can probably be some refactoring around verifyResponseByInvokingProviderMethods and verifyMessage to split common functionality into common methods, since mostly the only change is how to call the method and get the return value.

[solarmosaic-kflorence]

I am hoping we can apply this change first to the underlying Provider library before we need to implement it in all the other places, if that’s possible.

[uglyog]

4.1.25 released