bethesque

# Notes:
# Headers and status would still be value based matching
# Default to type based matching???

# like(xxx) means xxx and all children would be matched using type based matching
# literal(xxx) means xxx and all children would be matched using exact value matching
# eg(generate, matcher) would be a regular expression match
# each_like([]) would indicate the each element in the array should be like the example given
# A like() could be nested inside a literal() which could be nested inside a like() - at each stage, 
# it changes the matching type for all children until it gets switched back. 

bethesque

Assumptions based on experience with pacts so for:

• The most common type of matching that is useful is asserting that:
  • The expected keys are present
  • The values at the actual keys are of the same class (string/number/nil) as the expected values
  • Occasionally we'll want a literal match
  • Occasionally we'll want a regular expresssion
  • Extra keys in a hash are OK for responses but not for requests (following the "be strict with what you send out, be lax with what you accept" principle)
  • Extra items in an array are debatable (extra keys in a hash are generally ignored, however, all items in an array are generally processed, so allowing "unverified" extras to sneak in could be a bad thing. Working out what to do with "extras" is not immediately obvious to me however.)

bethesque

ClassNamesAreLikeThis
ModuleNamesAreLinkThis
def method_names_are_like_this
local_variable_names_are_like_this
@instance_variable_names_are_like_this
CONTSTANT_NAMES_ARE_LIKE_THIS

module Things
  class UserThing
    

bethesque

It's about ensuring the model used to stub client responses can actually be produced by the response you expect. Imagine your client returns a model like so:

class MyModel
   attr_reader :timestamp
   
   def initialize attrs
      @timestamp = attr[:timestamp]
   end
end

bethesque

# $ pact service -p 8080
# (new window)
# $ ruby preload-interactions.rb
# $ curl localhost:8080/path_one #Yay all good!
# $ curl localhost:8080/path_two #Boo... which response do we want???

require 'json'
require 'net/http'
require 'pact/consumer/consumer_contract_builder'
require 'pact/consumer_contract'

bethesque

class InternalProviderClient
  def thing
    #get a thing from the internal provider
  end
end

# pact_helper

Pact.configure do | config |
  config.pactfile_write_mode = :update

bethesque

You will need ruby or the standalone mock service to run these examples.

$ gem install pact-mock_service

bethesque

Pact is great for HTTP microservices that communicate directly with each other, but many services use an intermediate system that acts as a pipe (eg. a queue, S3 bucket). The agreement about the format of the message is really between the two ends of the chain, not between the links immediatly adjacent.

The pact concept should be able to be applied to non-http services. The code below is an attempt to come up with a DSL for a new pact library that uses the same pact matching concepts, but does not constrain the communication protocol.

Thoughts/improvements appreciated, but remember Gists do not send notifications when you post a comment :|

bethesque

POST to create a new resource in a collection

https://github.com/bethesque/pact_broker/blob/master/lib/pact_broker/api/resources/pacticipants.rb

POST to "do something"

https://github.com/bethesque/pact_broker/blob/master/lib/pact_broker/api/resources/webhook_execution.rb

PUT

https://github.com/bethesque/pact_broker/blob/master/lib/pact_broker/api/resources/pact.rb

GET single resource

bethesque

GET

• Override resource_exists?, content_types_provided, allowed_methods, and implement the method to render the resource.

class OrderResource < Webmachine::Resource
  def allowed_methods
    ["GET"]
  end
  
 def content_types_provided