pact 1.0.39 → 1.1.0.rc1

data/CHANGELOG.md

@@ -1,22 +1,6 @@
 Do this to generate your change history
 
-    git log --pretty=format:'  * %h - %s (%an, %ad)'
-
-### 1.0.39 (8 April 2014)
-
-* a034ab6 - Oh ActiveSupport, why??? Fixing to_json for difference indicators (bethesque, Mon Apr 7 17:26:10 2014 +1000)
-  * 1c7fa0d - Update faq.md (bethesque, Thu Apr 3 09:58:02 2014 +1100)
-  * 8cf5b57 - Update README.md (bethesque, Thu Mar 27 13:38:13 2014 +1100)
-  * 1c5fde9 - Preloading app before suite in pact:verify Ensures consistent behaviour between the first before/after each hooks (bethesque, Thu Mar 27 10:0
-
-### 1.0.38 (24 March 2014)
-
-* 7fb2bc3 - Improved readability of pact:verify specs by removing pactfile name and request details from output (bethesque, 23 hours ago)
-* ff1de3c - Improving readability of error messages when pact:verify fails (bethesque, 23 hours ago)
-* 8a08abf - Removed the last RSpec private API usage. I think. (bethesque, 33 hours ago)
-* 6a0be58 - Reducing even more use of RSpec private APIs (bethesque, 33 hours ago)
-* e1fd51c - Reducing use of RSpec private APIs (bethesque, 34 hours ago)
-* 587cb90 - Replaced rspec 'commands to rerun failed examples' with Pact specific commands to rerun failed interactions (bethesque, 2 days ago)
+    git log --date=relative --pretty=format:'  * %h - %s (%an, %ad)'
 
 ### 1.0.37 (19 March 2014)
 

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    pact (1.0.39)
+    pact (1.1.0.rc1)
       awesome_print (~> 1.1)
       colored
       find_a_port (~> 1.0.1)
@@ -58,7 +58,7 @@ GEM
     rspec-mocks (2.14.3)
     safe_yaml (0.9.5)
     slop (3.4.6)
-    thor (0.19.1)
+    thor (0.18.1)
     thread_safe (0.1.3)
       atomic
     tzinfo (0.3.38)

data/README.md

@@ -28,15 +28,14 @@ Travis CI Status: [![travis-ci.org Build Status](https://travis-ci.org/realestat
 ## Why is developing and testing with pacts better than using integration tests?
 
 * Faster execution.
+* No need to manage starting and stopping multiple processes.
 * 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.
 * 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.
 
-## Contact
+## Google users group
 
-* Twitter: [@pact_up](https://twitter.com/pact_up)
-* Google users group: https://groups.google.com/forum/#!forum/pact-support 
+https://groups.google.com/forum/#!forum/pact-support
 
 ## Installation
 
@@ -173,22 +172,13 @@ Create your API class using the framework of your choice (e.g. Sinatra, Grape) -
 
 #### 2. Tell your provider that it needs to honour the pact file you made earlier
 
-Require "pact/tasks" in your Rakefile.
-
-```ruby
-# In 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`.
 
 ```ruby
-# In specs/service_consumers/pact_helper.rb
-
 require 'pact/provider/rspec'
-# If you wish to use the same spec_helper file as your unit tests, require it here, but remember that the RSpec
+# If you wish to use the same spec_helper file as your unit tests, require it here.
 # Otherwise, you can set up a separate RSpec configuration in this file just for pact:verify.
+require './spec_helper'
 
 Pact.service_provider "My Service Provider" do
 
@@ -205,7 +195,13 @@ Pact.service_provider "My Service Provider" do
 end
 
 ```
+Require "pact/tasks" in your Rakefile. If the pact gem is in the test/development section of your Gemfile, you may want to put an env check around this so it doesn't load the pact tasks in prod.
 
+```ruby
+# In Rakefile
+
+require 'pact/tasks'
+```
 
 #### 3. Run your failing specs
 
@@ -213,13 +209,11 @@ end
 
 Congratulations! You now have a failing spec to develop against.
 
-At this 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:
+#### 4. Implement your service provider
 
-    $ rake pact:verify PACT_DESCRIPTION="a request for something" PACT_PROVIDER_STATE="something exists" 
+At this stage, you'll probably want to be able to run your specs one at a time while you implement. Define the environment variables PACT_DESCRIPTION and/or PACT_PROVIDER_STATE as so:
 
-#### 4. Implement enough to make your first interaction spec pass
-
-Rinse and repeat.
+    $ PACT_DESCRIPTION="a request for something" PACT_PROVIDER_STATE="something exists" rake pact:verify
 
 #### 5. Keep going til you're green
 
@@ -255,6 +249,8 @@ my_service.
         will_respond_with(status: 500, :body => {message: "An error occurred"}, :headers => { 'Content-Type' => 'application/json'} )
 ```
 
+
+
 To define service provider states that create the right data for "a thing exists" and "a thing does not exist", write the following in the service provider project. (The consumer name here must match the name of the consumer configured in your consumer project for it to correctly find these provider states.)
 
 
@@ -278,7 +274,6 @@ Pact.provider_states_for 'My Service Consumer' do
 
   provider_state "an error occurs while retrieving a thing" do
     set_up do
-      # Stubbing is ususally the easiest way to generate an error with predictable error text.
       ThingRepository.stub(:find).and_raise("An error occurred!")
     end
   end
@@ -382,13 +377,9 @@ Configure the pact_uri in the Pact.service_provider block with the pact artifact
 
 It should run with all your other tests. If an integration is broken, you want to know about it *before* you check in.
 
-#### In pact:verify on the provider, only stub layers beneath where contents of the request body are extracted
-
-If you don't _have_ to stub anything in the provider when running pact:verify, then don't. If you do need to stub something, make sure that you only stub the code that gets executed _after_ the contents of the request body have been extracted and/or validated, otherwise, there is no verification that what is included in the body of a request matches what is actually expected.
-
-#### Stub calls to downstream systems
+#### Use the real database
 
-Consider making a separate pact with the downstream system and using shared fixtures.
+Do not stub your database calls for pact:verify. This is the best time for you to test your database integration. If you stub your database calls, you are getting little more assurance that the real end-to-end will work than if you'd used a unit test. It's the appropriate time to incur the overhead of a database call.
 
 ## Gotchas
 

data/bethtest.rb

@@ -0,0 +1,30 @@
+require 'colored'
+
+puts "Key: #{'-'.red} expected, #{'+'.green} actual"
+
+puts '{
+  "_embedded": {'
+puts '-      "events": [
+-        {
+-          "probability": "75",
+-          "timestamp": "2014-03-03T14:00:00+00:00",
+-          "_embedded": {
+-            "opportunity": {
+-              "displayAdvertising": true,
+-              "_links": {
+-                "self": {
+-                  "href": "http://media-opportunities/opportunity-id-1"
+-                },
+-                "mediaProject": {
+-                  "href": "http://media-projects/project-id-1"
+-                }
+-              }
+-            }
+-          }
+-        }
+-      ]'.red
+puts '+    {
++    }'.green
+puts '  }
+}'
+

data/documentation/faq.md

@@ -1,24 +1,6 @@
 # Frequently asked questions
 
-### How does Pact differ from VCR?
-
-Pact is like VCR in reverse. VCR records actual provider behaviour, and verifies that the consumer behaves as expected. Pact records consumer behaviour, and verifies that the provider behaves as expected. The advantages Pact provides are:
-
-* The ability to develop the consumer (eg. a Javascript rich client UI) before the provider (eg. the JSON backend API).
-* The ability to drive out the requirements for your provider first, meaning you implement exactly and only what you need in the provider.
-* Well documented use cases ("Given ... a request for ... will return ...") that show exactly how a provider is being used.
-* The ability to see exactly which fields each consumer is interested in, allowing unused fields to be removed, and new fields to be added in the provider API without impacting a consumer. 
-* The ability to immediately see which consumers will be broken if a change is made to the provider API.
-* When using the [Pact Broker](https://github.com/bethesque/pact_broker), the ability to map the relationships between your services.
-
-### How does Pact differ from Webmock?
-
-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 verify a pact against a non-ruby provider?
+## 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).
 
@@ -30,20 +12,13 @@ Become famous, and write a pact-consumer library yourself! Then let us know abou
 
 ### How can I specify hooks to be executed before/after all examples for pact:verify?
 
-Use the set_up and tear_down hooks in the provider state definition:
+The pact:verify RSpec examples have the metadata `{:pact => :verify}` defined. You can add RSpec hooks using a filter as shown here:
 
 ```ruby
-
-Pact.provider_states_for "Some Consumer" do
-
-  set_up do
-    # Set up code here 
-  end
-
-  tear_down do
-    # tear down code here
+RSpec.configure do | config |
+  config.before :each, :pact => :verify do
+    # Your code here
   end
-
 end
 ```
 
@@ -66,10 +41,5 @@ This is a hotly debated issue.
 
 The pact authors' experience with using pacts to test microservices has been that using the set_up hooks to populate the database, and running pact:verify with all the real provider code has worked very well, and gives us full confidence that the end to end scenario will work in the deployed code.
 
-However, if you have a large and complex provider, you might decide to stub some of your application code. You will definitly need to stub calls to downstream systems. Make sure, when you stub, that you don't stub the code that actually parses the requests, because otherwise the consumer could be sending absolute rubbish, and you won't be checking it.
-
-### Why are the pacts generated and not hand coded?
-
-* Maintainability: Pact is "contract by example", and the examples may involve large quantities of JSON. Maintaining the JSON files by hand would be both time consuming and error prone. By dynamically creating the pacts, you have the option to keep your expectations in fixture files, or to generate them from your domain (the recommended approach, as it ensures your domain objects and their JSON representations in the pacts can never get out of sync).
+However, if you have a large and complex provider, you might decide to stub some of your application code. If you do, remember to add your own "verification" of your stubbed methods - write another test that will break if the behaviour of the stubbed methods changes.
 
-* Provider states: Dynamically setting expectations on the mock server allows the use of provider states, meaning you can make the same request more than once, with different expected responses, allowing you to properly test all your code paths.

data/lib/pact/configuration.rb

@@ -10,8 +10,6 @@ module Pact
     attr_accessor :tmp_dir
     attr_accessor :reports_dir
     attr_writer :pactfile_write_mode
-    attr_accessor :error_stream
-    attr_accessor :output_stream
 
     def log_path
       log_dir + "/pact.log"
@@ -56,8 +54,6 @@ module Pact
     c.logger = default_logger c.log_path
     c.pactfile_write_mode = :overwrite
     c.reports_dir = File.expand_path('./reports/pacts')
-    c.output_stream = $stdout
-    c.error_stream = $stderr
     c
   end
 

data/lib/pact/consumer/consumer_contract_builder.rb

@@ -84,7 +84,7 @@ module Pact
       end
 
       def warn_and_stderr msg
-        Pact.configuration.error_stream.puts msg
+        $stderr.puts msg
         logger.warn msg
       end
 

data/lib/pact/consumer_contract/active_support_support.rb

@@ -43,9 +43,5 @@ module Pact
       end
     end
 
-    def remove_unicode json
-      json.gsub(/\\u([0-9A-Za-z]{4})/) {|s| [$1.to_i(16)].pack("U")}
-    end
-
   end
 end

data/lib/pact/matchers/diff_decorator.rb

@@ -13,7 +13,7 @@ module Pact
       end
 
       def to_s
-        diff_descriptions(diff).join("\n")
+        diff_descriptions(diff).join("\n").tap{|s| puts s}
       end
 
       def diff_descriptions obj, path = [], descriptions = []

data/lib/pact/matchers/index_not_found.rb

@@ -1,12 +1,21 @@
-require 'pact/matchers/difference_indicator'
-
 module Pact
-  class IndexNotFound < Pact::DifferenceIndicator
+  class IndexNotFound
+    def == other
+      other.is_a? IndexNotFound
+    end
 
     def to_s
       "<index not found>"
     end
 
+    def to_json options = {}
+      as_json.to_json options
+    end
+
+    def as_json options = {}
+      to_s
+    end
+
     def empty?
       true
     end

data/lib/pact/matchers/matchers.rb

@@ -40,7 +40,7 @@ module Pact
 
     class NoDiffIndicator
 
-      def to_json
+      def to_json options = {}
         to_s
       end
 
@@ -58,6 +58,7 @@ module Pact
     DEFAULT_OPTIONS = {allow_unexpected_keys: true, structure: false}.freeze
 
     def diff expected, actual, opts = {}
+      # require 'pry'; pry(binding);
       options = DEFAULT_OPTIONS.merge(opts)
       case expected
       when Hash then hash_diff(expected, actual, options)

data/lib/pact/matchers/nested_json_diff_decorator.rb

@@ -0,0 +1,48 @@
+require 'pact/consumer_contract/active_support_support'
+require 'colored'
+
+module Pact
+  module Matchers
+    class NestedJsonDiffDecorator
+
+      include Pact::ActiveSupportSupport
+
+      EXPECTED = '"EXPECTED"'
+      EXPECTED_COLOURED = '"' + "expected".red + '"'
+      ACTUAL = '"ACTUAL"'
+      ACTUAL_COLOURED =  '"' + "actual".green + '"'
+
+      attr_reader :diff
+
+      def initialize diff
+        @diff = diff
+      end
+
+      def to_hash
+        diff
+      end
+
+      def to_s
+        colourise_message_if_configured fix_json_formatting(diff.to_json)
+      end
+
+      def colourise_message_if_configured message
+        if Pact.configuration.color_enabled
+          colourise_message message
+        else
+          message
+        end
+      end
+
+      def colourise_message message
+        message.split("\n").collect{| line | colourise(line) }.join("\n")
+      end
+
+      def colourise line
+        line.white.gsub(EXPECTED, EXPECTED_COLOURED).gsub(ACTUAL, ACTUAL_COLOURED)
+      end
+
+    end
+
+  end
+end

data/lib/pact/matchers/plus_minus_diff_decorator.rb

@@ -0,0 +1,92 @@
+module Pact
+  module Matchers
+
+    class PlusMinusDiffDecorator
+
+      def initialize diff
+        @diff = diff
+      end
+
+      def to_s
+        expected = generate_string(diff, :expected)
+        actual = generate_string(diff, :actual)
+
+        RSpec::Expectations::Differ.new.diff_as_string actual, expected
+      end
+
+      def handle thing, target
+        case thing
+        when Hash then copy_hash(thing, target)
+        when Array then copy_array(thing, target)
+        when Difference then copy_diff(thing, target)
+        when NoDiffIndicator then copy_no_diff(thing, target)
+        else copy_object(thing, target)
+        end
+      end
+
+      private
+
+      def generate_string diff, target
+        comparable = handle(diff, target)
+        begin
+          # Can't think of an elegant way to check if we can pretty generate other than to try it and maybe fail
+          JSON.pretty_generate(comparable)
+        rescue JSON::GeneratorError
+          comparable.to_s
+        end
+      end
+
+      def copy_hash hash, target
+        hash.keys.each_with_object({}) do | key, new_hash |
+          value = handle hash[key], target
+          new_hash[key] = value unless (KeyNotFound === value || UnexpectedKey === value)
+        end
+      end
+
+      def copy_array array, target
+        array.each_index.each_with_object([]) do | index, new_array |
+          value = handle array[index], target
+          new_array[index] = value unless (UnexpectedIndex === value || IndexNotFound === value)
+        end
+      end
+
+      def copy_no_diff(thing, target)
+        thing
+      end
+
+      def copy_diff difference, target
+        if target == :actual
+          copy_object difference.actual, target
+        else
+          copy_object difference.expected, target
+        end
+      end
+
+      def copy_object object, target
+        if Regexp === object
+          RegexpDecorator.new(object)
+        else
+          object
+        end
+      end
+
+      class RegexpDecorator
+
+        def initialize regexp
+          @regexp = regexp
+        end
+
+        def to_json options={}
+          @regexp.inspect
+        end
+
+        def as_json
+          @regexp.inspect
+        end
+      end
+
+      attr_reader :diff
+    end
+
+  end
+end