Procedure for releasing a pact consumer

[Indra Nara]

As I understand, we can have the provider build run the pact verifications using pact broker against both the production version of the consumers' contracts and also the latest and the provider build is a potential release candidate.

Trying to understand the consumer release procedures, how can I verify the latest consumer contract against the production version of the provider ? If I could do this, then the consumer build would also be a potential release candidate.

[Beth]

Hi Indra,

Yes, exactly. You'll need to keep track of the version of the provider code that is in production (eg. using tags or branches) and check that out into your build workspace. Then, run the pact verification tests against that codebase.

I wrote a blog post about testing this "matrix" here: http://rea.tech/enter-the-pact-matrix-or-how-to-decouple-the-release-cycles-of-your-microservices/

Beth

On Mon, May 23, 2016 at 8:20 AM, Indra Nara <naren...@gmail.com> wrote:

As I understand, we can have the provider build run the pact verifications using pact broker against both the production version of the consumers' contracts and also the latest and the provider build is a potential release candidate.

Trying to understand the consumer release procedures, how can I verify the latest consumer contract against the production version of the provider ? If I could do this, then the consumer build would also be a potential release candidate.

--
You received this message because you are subscribed to the Google Groups "Pact" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pact-support...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Indra Nara]

Hi Beth,

Thanks for the quick response.

Also, I am having a hard time selling pact to my team in the sense that we use DropwizardAppRule to standup the Jetty application and basically use the client to test the interface as part of the provider unit tests itself. By having a consumer provide a "pact" and then we conform to it, doesn't make a lot of sense to us.

More background: We have a client module that has the "model" object and the types of the elements are statically typed. So, our team is not able to see a lot of value and so do I. Can you provide me with more information as to where I can show the value of pact except for the fact that it is "consumer driven" and "conform to what consumer is expecting from the provider". 

Please advise.

Thanks.

[Beth]

Ron has done some Dropwizard work, got some thoughts on this Ron?

[Pierre]

Hi Indra,

I might be able to add to this conversation from our experience with Pact, and as a matter of fact we are also using DropWizard and we seem to be testing the Pacts in a similar way to yours.

Using unit tests for testing the pacts work quite well I find, but nothing says you can't have multiple pact unit tests. You can have one that tests against Prod of each consumer and one that tests against Head of each consumer.  

In your case (when the consumer changes):

- Consumer head generates a new contract during the build

- New contract gets published on the broker with "head" tag

- Get the Provider (in Prod branch) to run the pact unit test against the "head" contracts in the broker

Getting the provider to run these tests can be done by checking out the code of the provider (like Beth mentioned) or if you can do it with your CI, trigger a build of the provider to validate the head contracts (it's a bit nicer this way, as the consumer won't need to worry about how the build details of the provider, but it's definitely more set up in the CI).

Regarding your other question, the value comes from the fact that the code of your provider and consumer are independent, regardless of model objects and static types. If either the consumer or provider was to change that model object, the interaction would be broken and without a contract to validate this upfront you would only notice this at integration stage.

Hope this helps!

Pierre

[Ronald Holshausen]

Nice answer, Pierre!

Indra, if you are using the DropWizardApp rule, you can use the PactRunner from pact-jvm-provider-junit. It should work similar to this example: https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-junit#example-of-test

--

Ronald Holshausen

DiUS Computing Pty Ltd

Level 10, 99 Queens Street
Melbourne, VIC 3000

Phone: +61 3 9008 5400
Mobile: +61 413 162 439

http://www.diuscomputing.com.au

[Indra Nara]

Great answers everyone. I have a presentation after the long weekend to my team and hopefully I can sell this and add value. I am going to approach this in a slightly different manner and ask the team for ideas of doing integration at build time not telling about pact first and then run the idea of how pact is implemented. I think I have a better shot of having the team think about integration at build time. Again, thanks a bunch!

[Matt Fellows]

Start here: http://docs.pact.io/faq/convinceme.html

It's hard to be generic as every case is different, but if I understand correctly you have a Consumer client (website, app etc.) that communicates to a Provider API and you are testing the API via the client? In general, this is not a great idea for a number of reasons (many discussed, referenced in that above link). The gist of the problem is this: as the systems grows, this approach becomes less and less maintainable. e.g. what happens when you create a new client app that relies on this API? How do you know that you've captured all of the functionality / scenarios of the API? Using Pact, you can isolate the testing of these components whilst simultaneously increasing test coverage and reducing the time it takes to run those tests.

[Indra Nara]

Followed the example and I get this error, "No tests found for given includes: ... ". Which method does the actual pactverification ? I believe there should be an @Test (or) an @PactVerify ??

On Monday, May 23, 2016 at 8:10:43 PM UTC-4, Ronald Holshausen wrote:

[Ronald Holshausen]

Make sure you have the @RunWith(PactRunner.class) annotation on your test class.

For a template look at https://github.com/DiUS/pact-jvm/blob/master/pact-jvm-provider-junit/src/test/java/au/com/dius/pact/provider/junit/ContractTest.java

If you post your test class, it will help with diagnosing your issue.

[Indra Nara]

I do have the PactRunner. Following is the complete test class. Also, I am a little confused with regards to provider states. The consumer side createFragment() builder has the given() method; I am thinking that is to the set the provider state ?? There are also ways where we can setup provider states on the provide JUnit tests I believe, but I would prefer setting up the provider state on the consumer end of things so that my state and the contract tests are in one place. But, I am not sure if that is the issue here at all. Anyway, the test class is here:

@RunWith(PactRunner.class)

@Provider("test_provider")

@PactFolder("/Users/nnalabot/Git/uvvu-publisher/pacts")

public class ContractTest {

  @ClassRule

  public static final DropwizardAppRule<EventPublisherConfiguration> DW_RULE =

      new DropwizardAppRule<>(MockEventPublisherApplication.class, resourceFilePath("event-publisher.yml"),

          ConfigOverrideFile.config(resourceFilePath("test/event-publisher.properties"),

              ConfigOverride.config("server.applicationConnectors[0].port", AppRuleHelpers.getEnvAppPort()),

              ConfigOverride.config("server.adminConnectors[0].port", AppRuleHelpers.getEnvAdminPort())));

  public static final String BROADCAST_END_POINT = "https://push-receiver.herokuapp.com/receive-push";

  @Before

  public void setUp() throws Exception {

    traceId = TracingHeaders.generateTraceId();

  }

  @State("default")

  public void toDefaultState() {

  }

  @TestTarget

  public final Target target = new HttpTarget(8332);

[Ronald Holshausen]

Looks ok to me. I'll have to setup an example dropwizard project to test.

How are you running your tests? Via an IDE or using a commandline build tool?

[Indra Nara]

I tried both the IDE and also the "grade test" command line. But, I don't think Dropwizard has much to do here. It is just starting up the embedded Jetty.