New verification type: FUNCTION

[solarmosaic-kflorence]

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.

[uglyog]

How are the functions going to be specified in the test class?

[solarmosaic-kflorence]

@uglyog open to suggestions, but maybe something like:

interface IProviderVerifier {
  var verificationFunction: Function<String, Any>
}

Really just need one method that can take in the description and return the appropriate response.

[uglyog]

I was more referring to the user's test class. Will it need to be a public instance? The verifier class is not directly exposed to user code. We will need to support it across the implementations: Groovy, JUnit 4, JUnit 5, etc.

[solarmosaic-kflorence]

@uglyog it would need to be supplied to the ProviderVerifier I guess, similar to things like the method instance: new ProviderVerifier().setVerificationFunction(...) -- maybe there is a better way?

[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.

[solarmosaic-kflorence]

Maybe a better name is FACTORY_FUNCTION since it is essentially a factory for String -> response

[uglyog]

Pact-JS uses handlers https://github.com/pact-foundation/pact-js#provider-state-callbacks

[solarmosaic-kflorence]

It's probably best to support Future as well, if it's not too difficult. Function<String, Future<Any>> 🤔

[uglyog]

As long as it's java.util.concurrent.Future and not the Scala one

[uglyog]

4.1.25 released