pact 1.1.0 → 1.1.1

data/CHANGELOG.md

@@ -2,38 +2,49 @@ Do this to generate your change history
 
   git log --pretty=format:'  * %h - %s (%an, %ad)'
 
+### 1.1.1 (3 June 2014)
+
+* 503a3f4 - The pact verify executable now adds lib to the load path before requiring the pact_helper. (bethesque, Tue Jun 3 09:26:46 2014 +1000)
+* f62622e - Fixed output when a Pact::Term is expected in a response header. (bethesque, Tue Jun 3 07:18:52 2014 +1000)
+* bb5ae47 - Updated pact spec runner, matchers and pact verification code to work with both rspec 2.14 and 2.99. It's not pretty, but it does the job
+* c150e35 - Created a "pact verify" executable and change the rake task to invoke it to avoid the problem of cross contamination of requires (eg. wit
+* d981ab7 - Added "actual" response to pact:verify failure message to make it easier to identify the reason for failure. (bethesque, Tue May 20 21:49:06 2
+* a18787d - Added pact specification compliance spec. WIP. (bethesque, Tue May 20 21:48:10 2014 +1000)
+* 2d52356 - Adding back HTTP method and path to pact verify output, as it is otherwise impossible to tell from the output what the actual request was
+* 674d8c9 - Addd query to request.method_and_path (bethesque, Sat May 17 16:23:20 2014 +1000)
+
 ### 1.1.0 (5 May 2014)
 
 ### 1.1.0.rc5 (5 May 2014)
-  * dc9855b - Downcasing HTTP methods before sending call to RSpec::Test::Methods because pact-jvm is using an upcase method https://github.com/DiUS/pact-jvm/issues/34 (Beth, Mon May 5 12:29:51 2014 +1000)
-  * ddd4677 - Fixed problem of Pact::Terms displaying inside diff output by unpacking all the regular expressions before the diff is calculated (Beth, Mon May 5 12:16:25 2014 +1000)
+  * dc9855b - Downcasing HTTP methods before sending call to RSpec::Test::Methods because pact-jvm is using an upcase method https://github.com/DiUS/pact-jvm/issues/34 (bethesque, Mon May 5 12:29:51 2014 +1000)
+  * ddd4677 - Fixed problem of Pact::Terms displaying inside diff output by unpacking all the regular expressions before the diff is calculated (bethesque, Mon May 5 12:16:25 2014 +1000)
 
 ### 1.1.0.rc4 (1 May 2014)
 
-  * 5e1b78d - Display / in logs when path is empty https://github.com/realestate-com-au/pact/issues/14 (Beth, Thu May 1 22:09:29 2014 +1000)
-  * 01c5414 - Fixing doc generation bug where Pact::Terms were being displayed https://github.com/realestate-com-au/pact/issues/13 (Beth, Thu May 1 21:41:11 2014 +1000)
-  * 292a14b - Cleaning doc dir before generating new docs as per https://github.com/realestate-com-au/pact/issues/11 (Beth, Tue Apr 29 12:44:47 2014 +1000)
-  * 73c15dd - Changed default doc_dir to ./doc/pacts as per https://github.com/realestate-com-au/pact/issues/12 (Beth, Tue Apr 29 12:33:57 2014 +1000)
-  * 78ca78c - Fixed bug where log_dir was being ignored when set to a non default value (Beth, Tue Apr 29 07:50:32 2014 +1000)
+  * 5e1b78d - Display / in logs when path is empty https://github.com/realestate-com-au/pact/issues/14 (bethesque, Thu May 1 22:09:29 2014 +1000)
+  * 01c5414 - Fixing doc generation bug where Pact::Terms were being displayed https://github.com/realestate-com-au/pact/issues/13 (bethesque, Thu May 1 21:41:11 2014 +1000)
+  * 292a14b - Cleaning doc dir before generating new docs as per https://github.com/realestate-com-au/pact/issues/11 (bethesque, Tue Apr 29 12:44:47 2014 +1000)
+  * 73c15dd - Changed default doc_dir to ./doc/pacts as per https://github.com/realestate-com-au/pact/issues/12 (bethesque, Tue Apr 29 12:33:57 2014 +1000)
+  * 78ca78c - Fixed bug where log_dir was being ignored when set to a non default value (bethesque, Tue Apr 29 07:50:32 2014 +1000)
 
 ### 1.1.0.rc3 (28 April 2014)
 
-  * 41fa409 - Cleaned up consumer after spec failure message (Beth, Sun Apr 27 22:18:03 2014 +1000)
-  * 8593fa9 - Updated zoo-app example (Beth, Sun Apr 27 20:54:51 2014 +1000)
-  * 716e3a8 - Added standalone consumer spec and spec for VerificationGet (Beth, Thu Apr 24 10:15:17 2014 +1000)
-  * c0f9bc6 - Copied RSpec::Expectations::Differ to Pact::Matchers::Differ - safer than trying to override behaviour (Beth, Thu Apr 24 09:17:58 2014 +
-  * 0eeb032 - Changing default diff_formatter to unix (Beth, Thu Apr 24 08:19:15 2014 +1000)
+  * 41fa409 - Cleaned up consumer after spec failure message (bethesque, Sun Apr 27 22:18:03 2014 +1000)
+  * 8593fa9 - Updated zoo-app example (bethesque, Sun Apr 27 20:54:51 2014 +1000)
+  * 716e3a8 - Added standalone consumer spec and spec for VerificationGet (bethesque, Thu Apr 24 10:15:17 2014 +1000)
+  * c0f9bc6 - Copied RSpec::Expectations::Differ to Pact::Matchers::Differ - safer than trying to override behaviour (bethesque, Thu Apr 24 09:17:58 2014 +
+  * 0eeb032 - Changing default diff_formatter to unix (bethesque, Thu Apr 24 08:19:15 2014 +1000)
   * ace5d4d - Update README.md (bethesque, Wed Apr 23 20:59:24 2014 +1000)
   * 24efef6 - Update configuration.md (bethesque, Wed Apr 23 20:51:00 2014 +1000)
   * 2d862b7 - Update best-practices.md (bethesque, Wed Apr 23 07:33:01 2014 +1000)
-  * ff8dfd2 - Updated doco (Beth, Tue Apr 22 21:45:17 2014 +1000)
-  * 88e4572 - Moving best practices into its own file (Beth, Tue Apr 22 21:28:36 2014 +1000)
-  * 5a3b92c - Moving provider state documentation out of main README into it's own file. (Beth, Tue Apr 22 19:59:48 2014 +1000)
-  * 1d568c4 - Updated configuration documentation (Beth, Tue Apr 22 13:06:47 2014 +1000)
-  * be1412e - Added configuration documentation (Beth, Tue Apr 22 13:04:33 2014 +1000)
-  * 9f9d178 - Added HAL raq (Beth, Tue Apr 22 12:51:42 2014 +1000)
-  * d9b6479 - Renamed ListOfPathsFormatter to ListDiffFormatter (Beth, Tue Apr 22 12:48:57 2014 +1000)
-  * 6b82402 - Renamed NestedJsonDiffFormatter to EmbeddedDiffFormatter (Beth, Tue Apr 22 12:45:50 2014 +1000)
+  * ff8dfd2 - Updated doco (bethesque, Tue Apr 22 21:45:17 2014 +1000)
+  * 88e4572 - Moving best practices into its own file (bethesque, Tue Apr 22 21:28:36 2014 +1000)
+  * 5a3b92c - Moving provider state documentation out of main README into it's own file. (bethesque, Tue Apr 22 19:59:48 2014 +1000)
+  * 1d568c4 - Updated configuration documentation (bethesque, Tue Apr 22 13:06:47 2014 +1000)
+  * be1412e - Added configuration documentation (bethesque, Tue Apr 22 13:04:33 2014 +1000)
+  * 9f9d178 - Added HAL raq (bethesque, Tue Apr 22 12:51:42 2014 +1000)
+  * d9b6479 - Renamed ListOfPathsFormatter to ListDiffFormatter (bethesque, Tue Apr 22 12:48:57 2014 +1000)
+  * 6b82402 - Renamed NestedJsonDiffFormatter to EmbeddedDiffFormatter (bethesque, Tue Apr 22 12:45:50 2014 +1000)
   * def8afd - Merge branch 'master' into release-1.1.0 (bethesque, Tue Apr 22 09:13:41 2014 +1000)
   * 789a471 - Added generated docs to zoo-app (bethesque, Tue Apr 15 17:20:08 2014 +1000)
   * f5da7ab - Improved header match failure message (bethesque, Tue Apr 15 09:39:12 2014 +1000)

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    pact (1.1.0)
+    pact (1.1.1)
       awesome_print (~> 1.1)
       find_a_port (~> 1.0.1)
       json
@@ -27,7 +27,7 @@ GEM
     coderay (1.0.9)
     crack (0.4.1)
       safe_yaml (~> 0.9.0)
-    diff-lcs (1.2.4)
+    diff-lcs (1.2.5)
     fakefs (0.4.2)
     find_a_port (1.0.1)
     hashie (2.0.5)
@@ -45,16 +45,16 @@ GEM
       rack (>= 1.0)
     rake (10.0.4)
     randexp (0.1.7)
-    rspec (2.14.1)
-      rspec-core (~> 2.14.0)
-      rspec-expectations (~> 2.14.0)
-      rspec-mocks (~> 2.14.0)
-    rspec-core (2.14.5)
-    rspec-expectations (2.14.3)
+    rspec (2.99.0)
+      rspec-core (~> 2.99.0)
+      rspec-expectations (~> 2.99.0)
+      rspec-mocks (~> 2.99.0)
+    rspec-core (2.99.0)
+    rspec-expectations (2.99.0)
       diff-lcs (>= 1.1.3, < 2.0)
-    rspec-fire (1.2.0)
-      rspec (~> 2.11)
-    rspec-mocks (2.14.3)
+    rspec-fire (1.3.0)
+      rspec (>= 2.11, < 4)
+    rspec-mocks (2.99.0)
     safe_yaml (0.9.5)
     slop (3.4.6)
     term-ansicolor (1.3.0)
@@ -62,7 +62,7 @@ GEM
     thor (0.19.1)
     thread_safe (0.1.3)
       atomic
-    tins (1.1.0)
+    tins (1.3.0)
     tzinfo (0.3.38)
     webmock (1.9.3)
       addressable (>= 2.2.7)

data/README.md

@@ -10,13 +10,19 @@ This gem is inspired by the concept of "Consumer driven contracts". See http://m
 
 Travis CI Status: [![travis-ci.org Build Status](https://travis-ci.org/realestate-com-au/pact.png)](https://travis-ci.org/realestate-com-au/pact)
 
+## What is it good for?
+
+Pact is most valuable for designing and testing integrations where you (or your team/organisation/partner organisation) control the development of both the consumer and the provider. It is fantastic tool for intra-organsation microservices.
+
 ## Features
+
 * A service is mocked using an actual process running on a specified port, so javascript clients can be tested as easily as backend clients.
 * "Provider states" (similar to fixtures) allow the same request to be made with a different expected response.
 * Consumers specify only the fields they are interested in, allowing a provider to return more fields without breaking the pact. This allows a provider to have a different pact with a different consumer, and know which fields each cares about in a given response.
 * Rake tasks allow pacts to be verified against a service provider codebase.
 * Different versions of a consumer/provider pairs can be easily tested against each other, allowing confidence when deploying new versions of each (see the pact_broker and pact_broker-client gems).
 * Autogenerated API documentation - need we say more?
+* Coming soon - autogenerated network diagrams with the [Pact Broker](https://github.com/bethesque/pact_broker)
 
 ## How does it work?
 
@@ -24,13 +30,13 @@ Travis CI Status: [![travis-ci.org Build Status](https://travis-ci.org/realestat
 1. When the specs are run, the requests, and their expected responses, are written to a "pact" file.
 1. The requests in the pact file are later replayed against the provider, and the actual responses are checked to make sure they match the expected responses.
 
-## Why is developing and testing with pacts better than using integration tests?
+## Why is developing and testing with Pact better than using traditional system integration tests?
 
 * Faster execution.
-* Reliable responses from mock service provider reduce likelihood of flakey tests.
-* Only one component is being tested at a time, making the causes of test failures easier to identify.
+* Reliable responses from mock service reduce likelihood of flakey tests.
+* Causes of failure are easier to identify as only one component is being tested at a time.
 * Design of service provider is improved by considering first how the data is actually going to be used, rather than how it is most easily retrieved and serialised.
-* No need to manage starting, stopping and fixture set up for multiple applications during a test run.
+* No separate integration environment required for automated integration tests - pact tests run in standalone CI builds.
 
 ## Contact
 
@@ -172,9 +178,9 @@ Require "pact/tasks" in your Rakefile.
 require 'pact/tasks'
 ```
 
-Create a `pact_helper.rb` in your service provider project. The file must be called pact_helper.rb, however there is some flexibility in where it can be stored. The recommended place is `specs/service_consumers/pact_helper.rb`.
+Create a `pact_helper.rb` in your service provider project. The recommended place is `spec/service_consumers/pact_helper.rb`.
 
-See the [Provider](/documentation.md#provider) section of the Configuration documentation for more information.
+See [Verifying Pacts](documentation/verifying-pacts.md) and the [Provider](documentation/configuration.md#provider) section of the Configuration documentation for more information.
 
 ```ruby
 # In specs/service_consumers/pact_helper.rb
@@ -183,12 +189,10 @@ require 'pact/provider/rspec'
 
 Pact.service_provider "My Service Provider" do
 
-  app { MyApp.new } # Optional, loads app from config.ru by default
-
   honours_pact_with 'My Service Consumer' do
 
     # This example points to a local file, however, on a real project with a continuous
-    # integration box, you would publish your pacts as artifacts,
+    # integration box, you would use a [Pact Broker](https://github.com/bethesque/pact_broker) or publish your pacts as artifacts,
     # and point the pact_uri to the pact published by the last successful build.
 
     pact_uri '../path-to-your-consumer-project/specs/pacts/my_consumer-my_provider.json'
@@ -248,15 +252,15 @@ See the [Configuration](/documentation/configuration.md) section of the document
 
 As in all things, there are good ways to implement Pacts, and there are not so good ways. Check out the [Best practices](/documentation/best-practices.md) section of the documentation to make sure you're not Pacting it Wrong.
 
-## Gotchas
-
-* Be aware when using the app from the config.ru file is used (the default option) that the Rack::Builder.parse_file seems to require files even if they have already been required, so make sure your boot files are idempotent.
-
-
-See [Frequently Asked Questions](https://github.com/realestate-com-au/pact/blob/master/documentation/faq.md) and [Rarely Asked Questions](https://github.com/realestate-com-au/pact/blob/master/documentation/raq.md) and [Terminology](https://github.com/realestate-com-au/pact/blob/master/documentation/terminology.md) for more information.
+## Docs
 
+* [Example](example)
+* [Frequently Asked Questions](documentation/faq.md) 
+* [Rarely Asked Questions](documentation/raq.md)
+* [Terminology](documentation/terminology.md)
+* [Configuration](/documentation/configuration.md)
 
-## Related Gems
+## Related libraries
 
 [Pact Provider Proxy](https://github.com/bethesque/pact-provider-proxy) - Verify a pact against a running server, allowing you to use pacts with a provider of any language.
 
@@ -264,8 +268,20 @@ See [Frequently Asked Questions](https://github.com/realestate-com-au/pact/blob/
 
 [Pact Broker Client](https://github.com/bethesque/pact_broker-client) - Contains rake tasks for publishing pacts to the pact_broker.
 
+[Pact JVM](https://github.com/DiUS/pact-jvm) - A Pact implementation for the JVM (Java and Scala). It generates pact files that are compatible with the Ruby implementation.
+
 [Shokkenki](https://github.com/brentsnook/shokkenki) - Another Consumer Driven Contract gem written by one of Pact's original authors, Brent Snook. Shokkenki allows matchers to be composed using jsonpath expressions and allows auto-generation of mock response values based on regular expressions.
 
+## Links
+
+[Pact specification](https://github.com/bethesque/pact-specification)
+
+[Integrated tests are a scam](http://vimeo.com/80533536) - J.B. Rainsberger
+
+[Consumer Driven Contracts](http://martinfowler.com/articles/consumerDrivenContracts.html) - Ian Robinson
+
+[Integration Contract Tests](http://martinfowler.com/bliki/IntegrationContractTest.html) - Martin Fowler
+
 ## TODO
 
 Short term:

data/Rakefile

@@ -1,9 +1,9 @@
 require "bundler/gem_tasks"
 require 'rspec/core/rake_task'
 
-Dir.glob('lib/tasks/**/*.rake').each { |task| load task }
-Dir.glob('tasks/**/*.rake').each { |task| load task }
+Dir.glob('./lib/tasks/**/*.rake').each { |task| load task }
+Dir.glob('./tasks/**/*.rake').each { |task| load task }
 RSpec::Core::RakeTask.new(:spec)
 
-task :default => [:spec, :spec_with_active_support, 'spec:standalone:pass', 'pact:tests']
+task :default => [:spec, 'pact:tests:all', :spec_with_active_support, 'pact:tests:all:with_active_support']
 

data/documentation/README.md

@@ -7,4 +7,5 @@
 * [Frequently asked questions](faq.md)
 * [Rarely asked questions](raq.md)
 * [Best practices](best-practices.md)
+* [Troubleshooting](troubleshooting.md)
 * [Testing with pact diagram](Testing with pact.png)

data/documentation/development-workflow.md

@@ -0,0 +1,22 @@
+# Development Workflow
+
+Using consumer driven contracts enables you to reverse the "normal" order of development, allowing you to build your consumer, in its entirety if need be, before you build your provider.
+
+The development process will be different for every organisation, but this is one that has worked for the pact authors.
+
+## Initial development
+1. Write consumer tests with pact
+1. Implement consumer 
+1. Add `pact:publish` task to consumer build or publish pact as CI artifact
+1. Create provider project
+1. Configure pact:verify task to point to latest published pact
+1. Implement provider until `pact:verify` passes
+
+## New features
+
+1. Add new feature, with pact specs, to consumer project on a branch.
+1. In the provider project, use `rake pact:verify:at[/path/to/pact/on/branch]` to verify the new pact.
+1. Commit/release new provider feature.
+1. Merge consumer branch into master.
+
+This may seem complex, but it is actually sufacing the underlying reality, that you cannot add new functionality to the consumer before it can be supported by the provider, but that the functionality that the provider supports should still be driven by the needs of the consumer.

data/documentation/faq.md

@@ -18,6 +18,14 @@ Unlike Webmock:
 * Pact provides verification that the responses that have been stubbed are actually the responses that will be returned in the given conditions.
 * Pact runs a mock server in an actual process, rather than intercepting requests within the Ruby code, allowing Javascript rich UI clients to be tested in a browser.
 
+### How can I handle versioning?
+
+Consumer driven contracts to some extent allows you to do away with versioning. As long as all your contract tests pass, you should be able to deploy changes without versioning the API. If you need to make a breaking change to a provider, you can do it in a multiple step process - add the new fields/endpoints to the provider and deploy. Update the consumers to use the new fields, then deploy. Remove the old fields/endpoints from the provider and deploy. At each step of the process, all the contract tests remain green.
+
+Using a [Pact Broker]((https://github.com/bethesque/pact_broker), you can tag the production version of a pact when you make a release of a consumer. Then, any changes that you make to the provider can be checked agains the production version of the pact, as well as the latest version, to ensure backward compatiblity.
+
+If you need to support multiple versions of the provider API concurrently, then you will probably be specifying which version your consumer uses by setting a header, or using a different URL component. As these are actually different requests, the interactions can be verified in the same pact without any problems.
+
 ### How can I verify a pact against a non-ruby provider?
 
 You can verify a pact against any running server, regardless of language, using [pact-provider-proxy](https://github.com/bethesque/pact-provider-proxy).

data/documentation/provider-states.md

@@ -2,6 +2,8 @@
 
 Provider states allow you to set up data on the provider before the interaction is run, so that it can make a response that matches what the consumer expects. It also allows the consumer to make the same request with different expected responses.
 
+Keep in mind that a provider state is all about the state of the *provider* (eg. what data is there), not about the state of the consumer or the request.
+
 ### Consumer codebase
 
 For example, some code that creates a pact in a consumer project might look like this:

data/documentation/troubleshooting.md

@@ -0,0 +1,4 @@
+## Gotchas
+
+* Be aware when using the app from the config.ru file is used (the default option) that the Rack::Builder.parse_file seems to require files even if they have already been required, so make sure your boot files are idempotent.
+

data/documentation/verifying-pacts.md

@@ -0,0 +1,97 @@
+# Verifying pacts
+
+"Verifying a pact" is the second step of the Pact testing process. Each request in the pact file is replayed against 
+the provider, and the response that is returned is compared with the expected response in the pact file, and if the two
+match, then we know the consumer and provider are compatible.
+
+To verify a pact, we must:
+
+1. Configure the location of the pact to be verified. This can be a HTTP URL, or a local file system path.
+
+2. Set up the data for the [provider states](/documentation/provider-states.md).
+
+## Using rake pact:verify
+
+Using the pact:verify task is the default way to verify pacts. It is made available by requiring `'pact/tasks'` in your Rakefile.
+
+```ruby
+# In Rakefile
+require 'pact/tasks'
+```
+
+The pacts that will be verified by the pact:verify task are configured in the pact_helper.rb file in your provider codebase.
+The file must be called pact_helper.rb, however there is some flexibility in where it can be stored.
+The recommended place is `spec/service_consumers/pact_helper.rb`.
+
+To ensure that the latest version of the consumer pact is used each time, it is recommended that you either use a [Pact Broker](https://github.com/bethesque/pact_broker)
+or that you publish the pacts of a successful consumer build as artefacts in your CI system.
+
+```ruby
+# In specs/service_consumers/pact_helper.rb
+
+require 'pact/provider/rspec'
+
+Pact.service_provider "My Service Provider" do
+
+  app { MyApp.new } # Optional, loads app from config.ru by default
+
+  honours_pact_with 'My Service Consumer' do
+
+    # This example points to a local file, however, on a real project with a continuous
+    # integration box, you would publish your pacts as artifacts,
+    # and point the pact_uri to the pact published by the last successful build.
+
+    pact_uri '../path-to-your-consumer-project/specs/pacts/my_consumer-my_provider.json'
+  end
+
+  # This block is repeated for every pact that this provider should be verified against.
+  honours_pact_with 'Some other Service Consumer' do
+    ...
+  end  
+  
+end
+```
+
+## Using rake pact:verify:at
+
+You can also verify a pact at any arbitrary local or remote URL using the `pact:verify:at` task.
+This is useful when you are writing the consumer and provider concurrently, and wish to 
+
+    $ rake pact:verify:at[../path-to-your-consumer-project/specs/pacts/my_consumer-my_provider.json]
+    $ rake pact:verify:at[http://build-box/MyConsumerBuild/latestSuccessful/artifacts/my_consumer-my_provider.json]
+
+
+## Using a custom pact:verify task
+
+To make a shortcut task for verifying a pact an arbitrary URL that you do not want to verify as part of your normal pact:verify task,
+(eg. when you are developing the consumer and provider side by side, and want a shorter feedback cycle than can be provided by
+by your CI box) add the following to your Rakefile. The pact.uri may be a local file system path or a remote URL.
+
+```ruby
+# In Rakefile or /tasks/pact.rake
+
+# This creates a rake task that can be executed by running
+# $ rake pact:verify:dev
+
+Pact::VerificationTask.new(:dev) do | pact |
+  pact.uri '../path-to-your-consumer-project/specs/pacts/my_consumer-my_provider.json'
+end
+```
+
+## Running one pact at a time
+
+At some stage, you'll want to be able to run your specs one at a time while you implement each feature. At the bottom of the failed pact:verify output you will see the commands to rerun each failed interaction individually. A command to run just one interaction will look like this:
+
+    $ rake pact:verify PACT_DESCRIPTION="a request for something" PACT_PROVIDER_STATE="something exists"
+
+## Pact Helper location
+
+The search paths for the pact_helper are:
+
+```ruby
+[
+  "spec/**/*service*consumer*/pact_helper.rb",
+  "spec/**/*consumer*/pact_helper.rb",
+  "spec/**/pact_helper.rb",
+  "**/pact_helper.rb"]
+```

data/lib/pact/app.rb

@@ -7,12 +7,90 @@ require 'rack/handler/webrick'
 module Pact
   class App < Thor
 
-    desc 'service', "starts a mock service"
+    desc 'verify', "Verify a pact"
+    method_option :pact_helper, aliases: "-h", desc: "Pact helper file", :required => true
+    method_option :pact_uri, aliases: "-p", desc: "Pact URI"
+
+    def verify
+      RunPactVerification.call(options)
+    end
+
+    desc 'service', "Start a mock service"
     method_option :port, aliases: "-p", desc: "Port on which to run the service"
     method_option :log, aliases: "-l", desc: "File to which to log output"
     method_option :quiet, aliases: "-q", desc: "If true, no admin messages will be shown"
 
     def service
+      RunStandaloneMockService.call(options)
+    end
+
+    private
+
+    def log message
+      puts message unless options[:quiet]
+    end
+  end
+
+  class RunPactVerification
+
+    attr_reader :options
+
+    def initialize options
+      @options = options
+    end
+
+    def self.call options
+      new(options).call
+    end
+
+
+    def call
+      setup_load_path
+      load_pact_helper
+      run_specs
+    end
+
+    private
+
+    def setup_load_path
+      require 'pact/provider/pact_spec_runner'
+      lib = Dir.pwd + "/lib" # Assume we are running from within the project root. RSpec is smarter about this.
+      $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+    end
+
+    def load_pact_helper
+      load options[:pact_helper]
+    end
+
+    def run_specs
+      exit_code = if options[:pact_uri]
+        run_with_pact_uri
+      else
+        run_with_configured_pacts
+      end
+      exit 1 unless exit_code == 0
+    end
+
+    def run_with_pact_uri
+      Pact::Provider::PactSpecRunner.new([{uri: options[:pact_uri]}], pact_spec_options).run
+    end
+
+    def run_with_configured_pacts
+      pact_verifications = Pact.configuration.pact_verifications
+      verification_configs = pact_verifications.collect { | pact_verification | { :uri => pact_verification.uri }}
+      raise "Please configure a pact to verify" if verification_configs.empty?
+      Pact::Provider::PactSpecRunner.new(verification_configs, options).run
+    end
+
+    def pact_spec_options
+      {criteria: SpecCriteria.call}
+    end
+
+  end
+
+  class RunStandaloneMockService
+
+    def self.call options
       service_options = {}
       if options[:log]
         log = File.open(options[:log], 'w')
@@ -25,10 +103,26 @@ module Pact
       trap(:INT) { Rack::Handler::WEBrick.shutdown }
       Rack::Handler::WEBrick.run(mock_service, :Port => port, :AccessLog => [])
     end
+  end
 
-    private
-    def log message
-      puts message unless options[:quiet]
+  class SpecCriteria
+
+    def self.call
+      criteria = {}
+
+      description = ENV["PACT_DESCRIPTION"]
+      criteria[:description] = Regexp.new(description) if description
+
+      provider_state = ENV["PACT_PROVIDER_STATE"]
+      if provider_state
+        if provider_state.length == 0
+          criteria[:provider_state] = nil #Allow PACT_PROVIDER_STATE="" to mean no provider state
+        else
+          criteria[:provider_state] = Regexp.new(provider_state)
+        end
+      end
+
+      criteria
     end
   end
 end