CODEWITHSUNDEEP
microservicespactpact-jvm
Laiku
Laiku

Reputation: 21

PACT provider verification against public APIs

am trying to do test for consumer driver contract testing using pact jvm and able to generate consumer side contract file.During provider side verification, how to provide public API's instead of localhost most of the examples uses only localhost as provider, any help pls

@RunWith(PactRunner.class) // Say JUnit to run tests with custom Runner
@Provider("WeatherProvider") // Set up name of tested provider
@PactFolder("D:\Workspace\pactConsumer\pactConsumer_v2\pacts") // Point where to find pacts (See also section Pacts source in documentation)
@VerificationReports(value = {"markdown","json"}, reportDir = "D:\Workspace\pactConsumer\pactConsumer_v2\target")

public class ProviderVerifyer {
@State("Weather information is available for Chennai") // Method will be run before testing interactions that require "with-data" state
public void getWeather() {
System.out.println("Weather information is available for Chennai" );
}
@TestTarget // Annotation denotes Target that will be used for tests
public final Target target = new HttpTarget(8114); // Out-of-the-box implementation of Target (for more information take a look at Test Target section)

}

Upvotes: 2

Views: 995

Answers (1)

Timothy Jones
Timothy Jones

Reputation: 22165

This is possible, but-

You'll want to think carefully before verifying against a live provider - especially one that you don't control. Anything that changes server state is (very probably) out.

However, there's no technical reason you can't run some provider verification to check that your consumer contract is fulfilled by the currently deployed provider. There are constructors for host and port:

public final Target target = new HttpTarget(host, port);

Some things to be careful of:

  • It will be very important to write your tests so that they don't depend on the data. This means using matchers in your consumer tests to ensure that you're validating the shape of the data returned from the provider (rather than validating specific data returned from the provider). This is good practice for writing consumer tests anyway.
  • You may run into problems if your contract includes requests that are expected to change server state (it may not be appropriate to make these requests to a live provider, unless you're able to make the requests to a sandbox environment somehow).
  • Depending on the size of your contract and/or the normal traffic that the provider gets, it may be impolite to run your own automated tests against it.
  • You won't be able to set provider state. Provider states are used to avoid having interdependencies between your contract tests, so if you have to (say) make login requests before doing anything else, you are likely to run into headaches - pact is not designed to have tests that are order dependent or include more than one request.
  • Your tests may be brittle if they're going out to a live deployed provider running elsewhere- changes in DNS, server uptime, network timeouts, etc. all could cause your tests to fail unexpectedly.

A better alternative

The very best solution is to get whoever controls the provider to do their own verification, using (or including) the pact generated by your consumer. This is a good use case for a pact broker - but depending on your ability to contact the right people, may be a challenge.

Upvotes: 0

Related Questions