Beth Skurrie 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.)

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

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 :|

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

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

	# 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.

	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

	# $ 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'

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

	# pact_helper

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

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

	$ gem install pact-mock_service