Pactflow Code Demos

Introduction

Demo script

All demos are designed to fit in a 60 minute time slot, with the rough split of 5 minutes for introductions, 45 minutes for the demo, and 10 minutes for Q&A and follow up actions.

Here is a rough guide for how we run each demo:

Preparation

StepDescriptionPurposeDuration
1Run through slides 1 - 27 of demo packProblem statement, solution (contract-testing)5 mins
2Choose a technology mix to construct a scenario relevant to your customer (you can mix and match consumer/provider technology for comparable use cases)Setup demon/a
3Setup the integration in your Pactflow account (see CI/CD workshop for pre-requisites)Ensure the Demo Gods are on your side10 - 15 minutes

During the session

StepDescriptionPurposeDuration
4Show the consumer + provider working together in action (i.e. run them locally)Understand use case2 minutes
5Show consumer code + integration point (class/object) being testedConsumer test scope5 minutes
6Show consumer pact test code and step through the consumer pact tests (e.g. make test)How to write Pact tests5 mins
7Run the fake (make fake_ci) CI process (or show the real via a git push)Demonstrate a CI/CD workflow5 mins
(Optional) show how you can use pact-stub-service to run the consumer offlineDemonstrate value for local testing ahead of a real provider2 mins
8Show that the contract was published (tagged master) to Pactflow and basic featuresWhy Pactflow/Pact Broker exists2 minutes
8Explain what just happened with the can-i-deploy stepThe "magic moment" feature2 minutes
9Show provider code + integration point (class/object) being testedProvider test scope2 minutes
10Show provider pact test code and step through the provider pact test (e.g. make test)How to verify a Provider5 mins
11Run the fake (make fake_ci) CI process (or show the real via a git push)Demonstrate a CI/CD workflow5 mins
The provider build should pass, and is now deployed to production (denoted by the prod tag in Pactflow)--
12Re-run the consumer ci/cd process (make fake_ci) and "deploy" to prodUnderstand value of Pactflow2 mins
Observe that it is now tagged as prod in PactflowUnderstand can-i-deploy and environment management via tags-

Optional variations

If time permits, you may want to extend the demo to show other scenarios such as.

1. Modify the single product route to be GET /products/:id

  • This can be initiated from the consumer side or the provider side
  • Show how Pact will prevent a breaking change from being introduced and that it facilitiates

Scenarios

Product Catalog System (HTTP/Messages)

Our standard example is a product catalog website (see React above) which consumes a basic Products API implementing the following HTTP interface. All demo languages implement this interface so that we can easily mix and match technologies.

EndpointExample Response
GET /products[{"id":"09","type":"CREDIT_CARD","name":"Gem Visa","version":"v1"},{"id":"10","type":"CREDIT_CARD","name":"28 Degrees","version":"v1"},{"id":"11","type":"PERSONAL_LOAN","name":"MyFlexiPay","version":"v2"}]
GET /product/1{"id":"09","type":"CREDIT_CARD","name":"Gem Visa","version":"v1"}
info

The single get product endpoint is not a spelling mistake, and is used to show evolution to more standard resource based design

Demos

Consumers

LanguageUse CaseFramework/TechDescription
JS/NodeJSWebReactReact JS website relying on a Products API
JS/NodeJSWebCypressExample demonstrating how Cypress could be used to generate consumer pacts
JavaMessagesKafkaJava Kafka consumer
NodeJSMessagesKafkaNodeJS Kafka consumer
JavaSOAPJavaJava SOAP API consumer (note: only compatible with the SOAP provider)
.NETAPI.NET.NET Products API consumer

Providers

LanguageUse CaseFramework/TechDescription
JS/NodeJSAPIExpress JSExpressJS API provider
JavaAPISpring BootJava Spring Boot API provider
JavaMessagesKafkaJava Kafka message provider
JavaSOAPJavaJava SOAP API provider (note: only compatible with the SOAP consumer)
.NETAPI.NET.NET API provider