pact-go | Pact is a contract testing framework | REST library

by pact-foundation Go Version: v2.0.0-beta.18 License: MIT

X-Ray Key Features Code Snippets Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | pact-go Summary

pact-go is a Go library typically used in Web Services, REST applications. pact-go has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

From the Pact website:. The Pact family of frameworks provide support for Consumer Driven Contracts testing. A Contract is a collection of agreements between a client (Consumer) and an API (Provider) that describes the interactions that can take place between them. Consumer Driven Contracts is a pattern that drives the development of the Provider from its Consumers point of view. Pact is a testing tool that guarantees those Contracts are satisfied. Read Getting started with Pact for more information for beginners.

Support

Quality

Security

License

Reuse

Support

pact-go has a low active ecosystem.

It has 744 star(s) with 96 fork(s). There are 15 watchers for this library.

It had no major release in the last 12 months.

There are 28 open issues and 113 have been closed. On average issues are closed in 448 days. There are 14 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of pact-go is v2.0.0-beta.18

Quality

pact-go has 0 bugs and 0 code smells.

Security

pact-go has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

pact-go code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

pact-go is licensed under the MIT License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

pact-go releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

It has 5417 lines of code, 305 functions and 56 files.

It has low code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of pact-go

Get all kandi verified functions for this library.

pact-go Key Features

No Key Features are available at this moment for pact-go.

pact-go Examples and Code Snippets

No Code Snippets are available at this moment for pact-go.

Community Discussions

Trending Discussions on pact-go

Provider Not Registering Interaction

QUESTION

Provider Not Registering Interaction

Asked 2018-Mar-15 at 16:19

I'm using the Pact Go implementation to try out contract testing. I've made a provider test that isn't working because I need to mock out my service's request to Twilio.

I've made one Pact object for the contract between my consumer and this provider, and then another one called twilioPact for the contract between my provider and Twilio. I've added an interaction for the POST to the Twilio endpoint, but in the pact.log I'm not seeing it get registered. My test is making the request correctly, but there's no interaction registered for it so I get the 500 error from the mock server.

Does anyone have any experience using Pact with a 'provider' that is also a 'consumer'?

EDIT: After talking with Matt Fellows I was informed that I was using Pact incorrectly, and shouldn't be trying to run a mock service while running a provider verification. I had suspected as much, but none of the examples I had seen were for a provider that had a dependency. I was able to get my provider verification to work by writing a consumer test and passing the generated pact file to the pact-stub-service to act as the mock to Twilio.

...

ANSWER

Answered 2018-Mar-15 at 10:39

Here's a few things to consider:

It's better to have two separate contract tests between your client <-> Twilio Adapter, and Twilio Adapter <-> Twilio. It's possible to do what you're doing, but it will make the tests more complicated and probably harder to read/comprehend. Testing them in isolation gives you much more control.
When doing the former contract test, rather then daisy chain another pact mock service for your Twilio Adapter's (Provider) dependency (Twilio), you're best using standard mock/stub tooling for this job - either code based mocks/doubles, service doubles (e.g. Mountebank) or the stub server shipped with Pact [1]. Don't forget you will get to validate these assumptions with the other contract test, so you're safe to do this.
It's possible that because you have two mock servers running (one to mock the Twilio Adapter and another to mock Twilio) that your requests are being sent to the same mock service, and getting all tangled up

[1] Here is are the list of binaries etc. that are shipped with pact-go:

Source https://stackoverflow.com/questions/49283145

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install pact-go

See below for how to automate this:.
Download the latest CLI tools of the standalone tools and ensure the binaries are on your PATH:
Unzip the package into a known location, and ensuring the pact and other binaries in the bin directory are on the PATH.
Run go get github.com/pact-foundation/pact-go@v1 to install the source packages
The following will install pact binaries into /opt/pact/bin:. NOTE: the above script installs the latest standalone tools at the time it was ran. It is recommended you pin the installation to a specific version of a release so that you may control the upgrade cycle.

Support

Pact tests tend to be quite long, due to the need to be specific about request/response payloads. Often times it is nicer to be able to split your tests across multiple files for manageability.

Find more information at: