Download the PHP package waylandace/pact-php without Composer
On this page you can find all versions of the php package waylandace/pact-php. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download waylandace/pact-php
More information about waylandace/pact-php
Files in waylandace/pact-php
Package pact-php
Short Description Enables consumer driven contract testing, following the PACT foundation principles.
License MIT
Homepage https://github.com/pact-foundation/pact-php
Informations about the package pact-php
Pact PHP
PHP version of Pact. Enables consumer driven contract testing. Please read the Pact.io for specific information about PACT.
Table of contents
- Versions
- Specifications
- Installation
- Basic Consumer Usage
- Start and Stop the Mock Server
- Create Consumer Unit Test
- Create Mock Request
- Create Mock Response
- Build the Interaction
- Make the Request
- Make Assertions
- Basic Provider Usage
- Create Unit Tests
- Start API
- Provider Verification
- Verify From Pact Broker
- Verify All from Pact Broker
- Verify Files by Path
- Tips
- Starting API Asynchronously
- Set Up Provider State
- Examples
Versions
8.X updates internal dependencies and libraries. This results in dropping PHP 7.3
7.x updates internal dependencies and libraries, mostly to Guzzle 7.X. This results in dropping support for PHP 7.2. 6.x updates internal dependencies, mostly surrounding the Amp library. This results in dropping support for PHP 7.1.
5.X adds preliminary support for async messages and pact specification 3.X. This does not yet support the full pact specification 3.X as the backend implementations are incomplete. However, pact-messages are supported.
The 4.X tags are accompany changes in PHPUnit 7.X which requires a PHP 7.1 or higher. Thus, 4.X drops support for PHP 7.0.
The 3.X tags are a major breaking change to the 2.X versions. To be similar to the rest of the Pact ecosystem, Pact-PHP migrated to leverage the Ruby backend. This mirrors the .Net, JS, Python, and Go implementations.
If you wish to stick with the 2.X implementation, you can continue to pull from the latest 2.X.X tag.
Specifications
The 3.X version is the version of Pact-PHP, not the pact specification version that it supports. Pact-Php 3.X supports Pact-Specification 2.X.
Installation
Install the latest version with:
Composer hosts older versions under mattersight/phppact
, which is abandoned. Please convert to the new package name.
Basic Consumer Usage
All of the following code will be used exclusively for the Consumer.
Start and Stop the Mock Server
This library contains a wrapper for the Ruby Standalone Mock Service.
The easiest way to configure this is to use a PHPUnit Listener. A default listener is included in this project, see phpunit.xml file configured to use the default. Keep in mind that both the test suite and the arguments array must be the same value.
Alternatively, you can start and stop as in whatever means you would like by following this example:
Create Consumer Unit Test
Create a standard PHPUnit test case class and function.
Click here to see the full sample file.
Create Mock Request
This will define what the expected request coming from your http service will look like.
You can also create a body just like you will see in the provider example.
Create Mock Response
This will define what the response from the provider should look like.
In this example, we are using matchers. This allows us to add flexible rules when matching the expectation with the actual value. In the example, you will see regex is used to validate that the response is valid.
Matcher | Explanation | Parameters | Example |
---|---|---|---|
term | Match a value against a regex pattern. | Value, Regex Pattern | $matcher->term('Hello, Bob', '(Hello, )[A-Za-z]') |
regex | Alias to term matcher. | Value, Regex Pattern | $matcher->regex('Hello, Bob', '(Hello, )[A-Za-z]') |
dateISO8601 | Regex match a date using the ISO8601 format. | Value (Defaults to 2010-01-01) | $matcher->dateISO8601('2010-01-01') |
timeISO8601 | Regex match a time using the ISO8601 format. | Value (Defaults to T22:44:30.652Z) | $matcher->timeISO8601('T22:44:30.652Z') |
dateTimeISO8601 | Regex match a datetime using the ISO8601 format. | Value (Defaults to 2015-08-06T16:53:10+01:00) | $matcher->dateTimeISO8601('2015-08-06T16:53:10+01:00') |
dateTimeWithMillisISO8601 | Regex match a datetime with millis using the ISO8601 format. | Value (Defaults to 2015-08-06T16:53:10.123+01:00) | $matcher->dateTimeWithMillisISO8601('2015-08-06T16:53:10.123+01:00') |
timestampRFC3339 | Regex match a timestamp using the RFC3339 format. | Value (Defaults to Mon, 31 Oct 2016 15:21:41 -0400) | $matcher->timestampRFC3339('Mon, 31 Oct 2016 15:21:41 -0400') |
like | Match a value against its data type. | Value | $matcher->like(12) |
somethingLike | Alias to like matcher. | Value | $matcher->somethingLike(12) |
eachLike | Match on an object like the example. | Value, Min (Defaults to 1) | $matcher->eachLike(12) |
boolean | Match against boolean true. | none | $matcher->boolean() |
integer | Match a value against integer. | Value (Defaults to 13) | $matcher->integer() |
decimal | Match a value against float. | Value (Defaults to 13.01) | $matcher->decimal() |
hexadecimal | Regex to match a hexadecimal number. Example: 3F | Value (Defaults to 3F) | $matcher->hexadecimal('FF') |
uuid | Regex to match a uuid. | Value (Defaults to ce118b6e-d8e1-11e7-9296-cec278b6b50a) | $matcher->uuid('ce118b6e-d8e1-11e7-9296-cec278b6b50a') |
ipv4Address | Regex to match a ipv4 address. | Value (Defaults to 127.0.0.13) | $matcher->ipv4Address('127.0.0.1') |
ipv6Address | Regex to match a ipv6 address. | Value (Defaults to ::ffff:192.0.2.128) | $matcher->ipv6Address('::ffff:192.0.2.1') |
Build the Interaction
Now that we have the request and response, we need to build the interaction and ship it over to the mock server.
Make the Request
Verify Interactions
Verify that all interactions took place that were registered. This typically should be in each test, that way the test that failed to verify is marked correctly.
Make Assertions
Verify that the data you would expect given the response configured is correct.
Basic Provider Usage
All of the following code will be used exclusively for Providers. This will run the Pacts against the real Provider and either verify or fail validation on the Pact Broker.
Create Unit Test
Create a single unit test function. This will test a single consumer of the service.
Start API
Get an instance of the API up and running. Click here for some tips.
If you need to set up the state of your API before making each request please see Set Up Provider State.
Provider Verification
There are three ways to verify Pact files. See the examples below.
Verify From Pact Broker
This will grab the Pact file from a Pact Broker and run the data against the stood up API.
Verify All from Pact Broker
This will grab every Pact file associated with the given provider.
Verify Files by Path
This allows local Pact file testing.
Tips
Starting API Asynchronously
You can use the built in PHP server to accomplish this during your tests setUp function. The Symfony Process library can be used to run the process asynchronous.
Set Up Provider State
The PACT verifier is a wrapper of the Ruby Standalone Verifier. See API with Provider States for more information on how this works. Since most PHP rest APIs are stateless, this required some thought.
Here are some options:
- Write the posted state to a file and use a factory to decide which mock repository class to use based on the state.
- Set up your database to meet the expectations of the request. At the start of each request, you should first reset the database to its original state.
No matter which direction you go, you will have to modify something outside of the PHP process because each request to your server will be stateless and independent.
Additional Examples
There is a separate repository with an end to end example for both the 2.X and 3.X implementations.
- pact-php-example for 3.X examples
- 2.2.1 tag for 2.X examples
Message support
This feature is preliminary as the Pact community as a whole is flushing this out. The goal is not to test the transmission of an object over a bus but instead vet the contents of the message. While examples included focus on a Rabbit MQ, the exact message queue is irrelevant. Initial comparisons require a certain object type to be created by the Publisher/Producer and the Consumer of the message. This includes a metadata set where you can store the key, queue, exchange, etc that the Publisher and Consumer agree on. The content format needs to be JSON.
To take advantage of the existing pact-verification tools, the provider side of the equation stands up an http proxy to callback to processing class. Aside from changing default ports, this should be transparent to the users of the libary.
Both the provider and consumer side make heavy use of lambda functions.
Consumer Side Message Processing
The examples provided are pretty basic. See examples\tests\MessageConsumer.
- Create the content and metadata (array)
- Annotate the MessageBuilder appropriate content and states
- Given = Provider State
- expectsToReceive = Description
- Set the callback you want to run when a message is provided
- The callback must accept a JSON string as a parameter
- Run Verify. If nothing blows up, #winning.
Provider Side Message Validation
This may evolve as we work through this implementation. The provider relies heavily on callbacks. Some of the complexity lies in a consumer and provider having many messages and states between the each other in a single pact.
For each message, one needs to provide a single provider state. The name of this provider state must be the key to run a particular message callback on the provider side. See example\tests\MessageProvider
- Create your callbacks and states wrapped in a callable object
- The array key is a provider state / given() on the consumer side
- It is helpful to wrap the whole thing in a lambda if you need to customize paramaters to be passed in
- Choose your verification method
- If nothing explodes, #winning
Usage for the optional pact-stub-service
If you would like to test with fixtures, you can use the pact-stub-service
like this:
All versions of pact-php with dependencies
ext-openssl Version *
ext-json Version *
composer/semver Version ^1.4.0|^3.2.0
amphp/amp Version ^2.5.1
amphp/byte-stream Version ^1.8
amphp/dns Version ^1.2.3
amphp/hpack Version ^3.1.0
amphp/http-server Version ^2.1
amphp/log Version ^1.1
amphp/process Version ^1.1.1
amphp/serialization Version ^1.0
amphp/socket Version ^1.1.3
amphp/sync Version ^1.4.0
amphp/cache Version v1.4.0
amphp/windows-registry Version v0.3.3
guzzlehttp/guzzle Version ^6.5|^7.2.0
phpunit/phpunit Version >=8.2.3