Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • A RESTful API for publishing and retrieving pacts
  • An embedded API browser for navigating the API
  • Displays provider verification results
  • Auto-generated documentation for each contract
  • Provides a “matrix” of compatible consumer and provider versions
  • Visualize your microservices
  • A CLI for your CI/CD
  • Docker Pact Broker
  • Webhooks
  • Conclusion

Was this helpful?

  1. Software craftsmanship
  2. Testing
  3. Improve the design and testing of your micro-services through CDC Tests

Pact broker : the missing piece of your Consumer-Driven Contract approach

Pact broker : the missing piece of your CDC approach

PreviousCDC testing made simple with PactNextImprove your test quality with Mutation testing

Last updated 4 years ago

Was this helpful?

The Pact Broker is an application for sharing for consumer driven contracts and verification results.

It is optimized for use with “pacts” (contracts created by the framework), but can be used for any type of contract that can be serialized to JSON.

Let’s deep dive into the functionalities offered by the broker :

A RESTful API for publishing and retrieving pacts

The question that you can ask yourself when you start a CDC approach is where do I store the contracts ? In the consumer repository ? in a dedicated repository for the contracts ? in external libraries ? Where ?

The broker has been implemented to solve this question. The only source of truth is the broker where I can :

  • Publish a contract

  • Retrieve a contract

An embedded API browser for navigating the API

The Broker comes with an embedded HAL browser that lets you navigate the API in your browser window by using the HAL relations in each resource.

The HAL specification also provides a built in method for providing documentation about a relation. You can navigate to this documentation in the HAL browser by clicking on the book icon next to that relation in the HAL browser.

Displays provider verification results

When a pact is verified against a provider, the outcome of that verification (pass or fail) needs to be made available to the consumer and provider teams, so they know whether or not the code in either project can be safely deployed.

The pact verification tool can automatically publish the verification results back to the broker, and they will be displayed on the index page next to the pact details.

By displaying verification results you know if you can deploy safely

Auto-generated documentation for each contract

A human readable version of the pact can be browsed from the broker :

Provides a “matrix” of compatible consumer and provider versions

When publishing a pact or a verification, the resource is associated with a particular version of the pacticipant (application), which is identified by a version number.

A pacticipant version number:

  • is expected to change (almost) every time a pact is published

  • should exist only on one branch of your code

  • should be known at release time (so you can pass it in to can-i-deploy to ensure that you are safe to release)

Visualize your microservices

Dynamically generated network diagrams so you can visualise your microservice network.

A CLI for your CI/CD

By using the can-i-deploy feature of the Pact Broker CLI, it will give you a definitive answer if the version of your consumer that is being deployed, is compatible with all of its providers.

This functionality can definitely save your life by avoiding an integration problem to arrive in production.

Docker Pact Broker

So it is really easy to setup and play with it with just a few lines of YAML :

Webhooks

Provides webhooks to trigger actions when pacts change eg. run provider build, notify a Slack channel. You can trigger a webhook for those events :

To create a new webhook you just need to POST it to your broker :

In the broker you will have feedback on it :

Conclusion

To conclude those articles I would like to say that Pact and Pact broker together are really great tools BUT I would like to remind that consumer-driven contract testing is a technique that requires no special tool to implement. If you want to start without tooling go ahead, tools are just there to support the approach.

Once again it is all about communication.

Communication between teams :

  • Team that will need to consume a service

  • Team that will provide the service

The Pact Broker API uses (Hypertext Application Language) as its hypermedia implementation (that is, the method of providing links within a resource to navigate from that resource to related resources).

should uniquely identify or be able to be mapped back to the commit of the code base that published a pact or verification (so that you can use tags to identify and checkout the the prod version of your provider if you wish to .)

A for incorporating the Pact workflow into your continuous integration process.

There is an official image for the broker available here :

HAL
test the "matrix"
CLI
https://hub.docker.com/r/pactfoundation/pact-broker/
Pact