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
  • What is Pact ?
  • How can we implement a new service with Pact ?
  • 1) Start with the consumer
  • 2) Contract Driven Development
  • Features offered by Pact
  • S.W.O.T
  • Resources
  • Conclusion

Was this helpful?

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

CDC testing made simple with Pact

PreviousImprove the design and testing of your micro-services through CDC TestsNextPact broker : the missing piece of your Consumer-Driven Contract approach

Last updated 4 years ago

Was this helpful?

What is Pact ?

Pact is a contract testing tool. Contract testing is a way to ensure that services (such as an API provider and a client) can communicate with each other. Without contract testing, the only way to know that services can communicate is by using expensive and brittle integration tests.

Pact provides a testing button for your code, allowing you to safely confirm that your applications will work together without having to deploy the world first.

It is available on a lot of platforms and languages :

Pact comes with its own specification regarding the format of the contracts between consumers and providers :

How can we implement a new service with Pact ?

Because we use a CDC approach we start with the consumer and here is what we want as a consumer :

As a consumer, I want a Rest API that returns “Hello world v1” when I GET “api/v1.0/helloworld”

1) Start with the consumer

Let’s implement a simple consumer by :

  • Writing Test(s)

  • Define interactions / Expectations

Concretely :

  • Build your client : here we call it consumer-js

  • Describe and configure the interactions (behaviors and expectations)

Once you have defined it you can run the tests. From those expectations Pact will create a contract file : a JSON file that will look like this :

2) Contract Driven Development

  • Design Your API From The Contract

  • Write a RED test

The RED test (in .NET Core)

The test will be launched and interactions will be verified based on the contract that has been defined on the consumer side.

Make the test GREEN

Features offered by Pact

In this simple example we have just checked a GET interaction with simple string matcher but you can achieve much more complex and more realistic verifications with the tool :

S.W.O.T

Based on our experience with Pact here is our S.W.O.T :

Resources

Conclusion

Pact is a really good tool to start a CDC approach. It is easy to use but there is one problem that needs to be solved before starting using it in enterprise :

Where the hell do we store the contracts ?

Please find the code samples in this repository :

To go further check the implementation guide in your favorite language :

https://github.com/agilepartner/pact-sandbox
https://docs.pact.io/implementation_guides