pact-foundation/pact-ruby

Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.

pact-ruby's Issues

Change the request and response validation to use paths mapped to matchers

The current validation of the requests and response bodies is by comparison of the whole expected body. It does allow more to be in the actual body, but it is awkward when the bodies get large.

One idea id to allow paths to be mapped to a matcher. This would work in a XPath or JSON Path style. That way you can have a number of paths to execute the matcher against.

Add rake pact::tests with ACTIVE_SUPPORT_LOADED

Pact::Term displays incorrectly in pact:verify output in 1.1.0.rc1

It should show the regular expression, not the json.

     Failure/Error: expect(response_body).to match_term expected_response_body
       {
         "_links": {
           "expected": {
             "self": {
               "href": {
                 "json_class": "Pact::Term",
                 "data": {
                   "generate": "http://localhost:1234/pacticipants/Condor/versions/1.3.0/tags/prod",
                   "matcher": {
                     "json_class": "Regexp",
                     "o": 0,
                     "s": "http://.*/pacticipants/Condor/versions/1.3.0/tags/prod"
                   }
                 }
               }
             }
           },
           "actual": "<key not found>"
         }
       }

Add instruction about showing full backtrace when provider verification fails

Allow rspec methods to be used within provider state blocks

I'd like to be able to use the new RSpec syntax while setting up provider states.

For example:

provider_state "some state exists" do
  set_up do
    allow(Foo).to receive(:bar).and_return('baz')
  end
end

The current workaround for this is simply to use the older deprecated RSpec syntax.

provider_state "some state exists" do
  set_up do
    Foo.stub(:bar).and_return('baz')
  end
end

Interactions are not cleared from standalone mock servers

Pact::Consumer::AppManager.instance.ports_of_mock_services probably only returns instances it has itself started up.

Diff formatter configuration seems to be ignored

I tried setting 'config.diff_formatter' to :embedded and :list, but the formatter that pact uses seems to always be :unix.

=> solved by including pact helper properly...

Document Pact::Term

Replace 'X-Pact-Mock-Service' with a separate HTTP port

The current server runs in the rspec process (on its own thread).

It would be possible to listen on a separate HTTP port, which would avoid (e.g.) having to stuff around checking X-Pact-Mock-Service.

Example provider has a uncompleted comment

See example in https://github.com/realestate-com-au/pact#2-tell-your-provider-that-it-needs-to-honour-the-pact-file-you-made-earlier

There is a comment that ends with ", but remember that the RSpec" ...

Remember what about the RSpec?

Use Appraisal to run tests against different versions of RSpec.

https://github.com/thoughtbot/appraisal

Support hashes for query param matching

I currently have a requirement to match a request with three query string parameters and at the moment the only way I can do this is to match the whole query string with the parameters in the "correct order" as per what is actually sent:

  describe "fetching updated agencies" do
    before do
      cp_services
        .given("an updated agency")
        .upon_receiving("a request for updated agencies")
        .with( method: :get, path: '/services/agencies', query: "updated_from=#{updated_from}&per_page=#{per_page}&api_key=#{api_key}" )

What I'd like to do is something like this:

  describe "fetching updated agencies" do
    before do
      cp_services
        .given("an updated agency")
        .upon_receiving("a request for updated agencies")
        .with( method: :get, path: '/services/agencies', query: { updated_from: updated_from, per_page: per_page, api_key: api_key } )

We can already do this sort of thing with HTTP headers so it would only make sense to make them work the same way

Create HTML documentation from pact files

Add support for RSpec 3

When the path is empty, display / in logs

Received request GET /

rather than

Received request GET

Include the pact specification version on the metadata section

This will allow us to start implementing the new matching, but still be able to validate pacts generated from the older versions.

Message for duplicate interaction should specify that the headers/body/path are differerent

RuntimeError:
       Interaction with same description (a request retrieve a committed revenue sync) and provider state (a committed-revenue-sync exists with ID 123) already exists

Duplicate description/provider state is allowed so long as the entire interaction itself is identical.

Suggested new message:

An interaction with same description (a request retrieve a committed revenue sync) and provider state (a committed-revenue-sync exists with ID 123) has already been used, however, its has different request and/or response details. Please use a new description or provider state.

Clean doc dir before generating API docs

Otherwise when a pact is removed, the documentation still exists.

Escape markdown chars in pacticipant names in markdown renderer

eg.

A pact between some_provider and some_consumer_thing

Header matching should be case insensitive

From RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1", paragraph 4.2, "Message Headers":

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

Move pact writing to mock server so it can be reused by consumer libraries in other languages

Cannot represent the same HTTP header being set multiple times.

It's valid to send a header more than once in HTTP, but the pactfile format cannot express it.

Change provider_state to providerState

pact-foundation/pact-specification#9

Add pictures to explanation about how pact works in README

Fail pact verification when there are no interactions?

Had situation where empty pact file was verified, no breaking build. Should this be the case?

Duplicate detection failing with SomethingLike

I mentioned on the mailing list that setting up an identical second interaction was being rejected when it contained a Pact::SomethingLike, but not when it contained a Pact::Term.

This is the track the issue.

I have not yet reproduced it on a small example, however, I have just noticed that in the json pact file, the Pact::SomethingLike is serialised to "amount": "#Pact::SomethingLike:0x00000002b10d58"
whereas the Pact::Term is correctly serialised to
"myobject": {
"json_class": "Pact::Term",
"data": {
"generate": "123",
"matcher": {
"json_class": "Regexp",
"o": 0,
"s": "\d+"
}
}
},

In my existing case, this is in the response body, a few level down in a hash, along the lines of:
body: {
data: {
embeded_data: {
name: Pact::Term(...)
}
}
info: {
amount: Pact::SomethingLike("20.00")
}
}

Maybe something is going wrong with a serialisation of Pact::SomethingLike when it's embedded a few level down in a hash.

Create pact init

Submit PRs to: https://github.com/bethesque/pact-init-consumer

pact-init-consumer --consumer "My Consumer" --provider "My Provider" should create
spec/service_providers/pact_helper.rb

require 'pact/consumer/rspec'

Pact.service_consumer 'My Consumer' do
  has_pact_with 'My Provider' do
    mock_service :my_provider do
      port 1234
    end
  end
end

--consumer and --provider should be optional, and if no values are given use "My Consumer" and "My Provider".

Submit PRs to: https://github.com/bethesque/pact-init-provider
pact-init-provider --provider "My Provider" --consumer "My Consumer" should create
spec/service_consumers/pact_helper.rb

require 'pact/provider/rspec'
require "service_consumers/provider_states_for_my_consumer"

Pact.service_provider 'My Provider' do
  honours_pact_with 'My Consumer' do
    pact_uri ''
  end
end

spec/service_consumers/provider_states_for_my_consumer.rb

Pact.provider_states_for 'My Consumer' do
  provider_state 'there is a thing' do
    set_up do
      # Set up the provider state here (eg. insert record into a database)
    end
  end
end

Default doc_dir should be doc/pacts

Clean up unused code in AppManager

Absolute URLs in responses

Hey folks,

We've got a server here which is generating a HAL response with absolute URLs. We're hitting a bit of a chicken and the egg problem, and I'm wondering if anyone has any suggestions (or if we're just doing something stupid).

• When running the specs with the mock server, the server is running on localhost:1234. The server uses req.host to generate absolute urls, which results in a HAL response containing http://localhost:1234/v1/blah. These urls are recorded in the pact.
• When verifying the pact, the requests are made with a Host header of example.org which obviously causes the server to respond with http://example.org/v1/blah, violating the pact.

I've tried not using req.host to generate the URL and instead making it a config setting for the app; however, the problem still exists that the mock server needs to listen on localhost:1234.

Ultimately, there always seems to be a mismatch between the hostname of the mock server, and the server the verification is being run against.

Any suggestions? Am I missing something obvious here?

Separate pact-server & pact

This would reduce the code size, making it much easier to identify e.g. concurrency bugs in the pact server implementation.

Update documentation on best practise regarding factories

As per https://github.com/realestate-com-au/pact/pull/29

Log warning when content type is missing

And text matcher is used.

CSV differ

Hi Beth,

I've created a CSV differ for pact.
It doesn't have tests yet and uses cucumber tables for diffing (which seems a little awkward), but it works in manual tests on an adapted example.
Maybe you can have a look if this goes in the right direction.
I don't know how much time I can spend on this, but hopefully get to write some basic tests at least.

Best
Martin

Set order of interactions in pact file

When rspec runs with random order, the interactions are added to the pact file in the random order, and hence, the pact file changes significantly each time, and it is hard to see what the actual genuine changes are. Allow the order of the interactions to be written consistently.

Document wait_for_interactions

And make the params optional

Support other body types than JSON

Currently Pact assumes everything is JSON.

We need to add a may to transform different mime types into something that can be compared. Initially only JSON and XML need be supported until someone finds a need for another format

Display request diffs in after hook for consumer

Current message

An error occurred in an after hook
  RuntimeError: Actual interactions do not match expected interactions for mock XXX.

Incorrect requests:
    POST /xxx (request body did not match)

See log/xxx_mock_service.log for details.

Showing diffs here would be easier than traipsing through logs.

Require a way to validate a pact against a running server

Not all apps are Rack apps. Sometimes we have integration points with servers outside our control.

We should allow the Pact verification to hit a running server instead of starting up a Rack app.

Two ideas:
Maybe the Pact.service_provider configuration could have a URL configuration instead of an app?

Pact.service_provider "Horrific Monolith" do
    base_url "http://blah"

   honours_pact_with ...
end

Or maybe just a rake task, seeing as you probably won't have an actual ruby project to run it in.

Pact::RunningAppVerificationTask.new do | task |
  task.pact_uri = "./spec/pacts/my-consumer_horrific_monolith.json"
  task.app_base_url = "http://blah"
end

Method case should not matter when matching requests

Running pact with existing contact

Ok following my twitter conversation that is probably better place to have proper discussion.
The scenario I have is the following

1. I generate contracts based on my consumer/service_providers/service_spec.rb
2. I would like to be able to use generated contracts to run set of tests(JS) using pact as replacement for real service. I figured out how to make pact run but it does not load any interactions.
   I have already generated the contract why can't we just add an option --contract so that server loads interactions from contract. They are generated from expected interactions so there should be a way to get expected interaction back from them.

Example of how TW does something similar -> https://github.com/thoughtworks/pacto#pacto-server-non-ruby-usage
As extra benefit that way pact can be used with any language at least to perform stubbing

Authentication tokens/step in pact.

So at the moment we are having to modify the pact.json files before running pact. This is for inserting authentication tokens with expiry in about 2 hours into the pacts.

pacts = File.join(File.dirname(File.expand_path(__FILE__)), '../src/test/resources/pacts/*.json')
Dir.glob(pacts).each do |f|
  text = File.read(f)
  output_of_gsub = text.gsub(/\"Authorization\"\s*:\s*\".+\"/) { "\"Authorization\": \"ioof-token #{token}\"" }
  File.open(f, "w") { |file| file.puts output_of_gsub }
end

It would be good to be able to nicely insert/modify headers of the request before they are sent without modifying the pact files.

Cheers,

For HAL responses, should pact mock service url "localhost:1234" be displayed in generated documentation?

When using a Pact::Term.new(generate: "http://localhost:1234/some-path", matcher: %r{http://.*/some-path})
Or should it be replaced with example.org? Or the regexp?

{
  "status": 200,
  "headers": {
    "Content-Type": "application/hal+json"
  },
  "body": {
    "_links": {
      "some-resource": {
        "href": "http://localhost:1234/some-resource"
      }
    }
  }
}

or

{
  "status": 200,
  "headers": {
    "Content-Type": "application/hal+json"
  },
  "body": {
    "_links": {
      "some-resource": {
        "href": "http://example.org/some-resource"
      }
    }
  }
}

or

{
  "status": 200,
  "headers": {
    "Content-Type": "application/hal+json"
  },
  "body": {
    "_links": {
      "some-resource": {
        "href": "http:\/\/.*/some-resource"
      }
    }
  }
}

Thoughts:
Regular expressions can be hard to read, example data is more meaningful, especially for something like a timestamp.

pact:verify broken with rspec-core 3.0.3

matches_an_exclusion_pattern() no longer exists.

Please lock rspec-core to 3.0.2 or earlier in the meantime.

Do not use ANSI colours when printing to non interactive terminal

eg.

�[31mActual interactions do not match expected interactions for mock Media Project Revenue.

Update header matching logic for cookies to match pact-jvm

johnelf/pact-jvm@211967e

Cookie with value 'a=b;c=d' should match 'c=d;e=f;a=b' as provider may add extra cookies that the consumer does not care about, and the order should not matter.

Pact::Terms are visible in the generated docs

"startDate": {
        "json_class": "Pact::Term",
        "data": {
          "generate": "2013-10-01T10:00:00.000Z",
          "matcher": {"json_class":"Regexp","o":0,"s":"\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z"}
        }
      }

It should show the example value.

Headers are modified when they shouldn't be

When using custom headers (Blah-Blah-Blah) all dashes are re-written as underscores (Blah_Blah_Blah).

Consumer tests correctly validate against dashes in the request, but when they're replayed back against the provider the headers get changed. Either the consumer tests should rewrite the headers to use underscores or the provider side shouldn't change the request. As it stands currently tests on one side will pass and the other will fail even though the specification is correct.

Add warning when no expectations are made of the response body for a post/put/patch

Each interaction is tested in isolation, meaning you can't do a PUT/POST/PATCH, and then follow it with a GET to ensure that the values you sent were actually read successfully by the provider. If you send a lastname instead of a surname field, a provider will most likely ignore the misnamed field, and return a 200, failing to alert you to the fact that your lastname has gone to the big /dev/null in the sky.

The code should warn you when a POST/PUT/PATCH request is defined, with a non-empty body, that does not make any expectations about the response.

Sign the pact gem