bethesque

This allows you do something like:

User = Struct.new(:address)
Address = Struct.new(:street, :suburb)

class UserForm < Reform::Form

  property :address do
 property :street

bethesque

class Thing::Create < Trailblazer::Operation

  def process(params)
    validate(params[:referral]) do
      authorize(params, model, :create?) 
      form.save
    end
  end

  def setup_model!(params)

bethesque

# pact-provider-proxy/vendor/rack-reverse-proxy/lib/rack/reverse_proxy.rb

require 'net/http'
require 'net/https'
require "rack-proxy"
require "rack/reverse_proxy_matcher"
require "rack/exception"

module Rack
  class ReverseProxy

bethesque

# Note: this does not migrate the tags

require 'faraday'
require 'json'

source_host = 'http://some-pact-broker'
destination_host = 'http://localhost:9292'

latest_pacts_response = JSON.parse(Faraday.get("#{source_host}/pacts/latest").body)
pact_hrefs = latest_pacts_response['pacts'].collect{ | pact | pact['_links']['self'][1]['href'] }

bethesque

When you declare a request and response using the traditional Pact DSL, ("uponReceiving" and "willRespondWith") you're building a structure that has three purposes -

1. it provides the concrete example request and response used in the tests
2. it specifies the contents of the contract which...
3. defines how to validate the the actual request/response against the expected request/response

The three different uses of this structure are hidden from you when using HTTP Pact because the mock service handles numbers 1 & 2 in the consumer tests, and the verification task handles number 3 for you in the provider tests. When using Pact in a non-HTTP scenario, there is no nice neat protocol layer to inject the code to do this for you, so you have to explicitly do each step.

The file expected_data_from_collector.rb declares an object graph using the Pact DSL. This is going to be used to create the concrete example and the contract. This could be declared inline, but for easier maintenance, and to allow the contr

bethesque

source 'https://rubygems.org'

gem 'pact', '~>1.7.0'

bethesque

require 'pact/provider/proxy/tasks'

Pact::ProxyVerificationTask.new :userapi_service do | task |
  task.pact_url './spec/pacts/userapi_service_consumer-userapi_service_provider.json'
  task.provider_base_url 'https://userapi.com/'
end

Pact::ProxyVerificationTask.new :otherapi_service do | task |
  task.pact_url './spec/pacts/otherapi_service_consumer-otherapi_service_provider.json'
  task.provider_base_url 'https://otherapi.com'

bethesque

# gem "omniauth-github"
# gem "rack-rewrite"

require 'fileutils'
require 'logger'
require 'sequel'
require 'pact_broker'
require 'omniauth/strategies/github'
require 'rack/rewrite'

bethesque

Our tests should:

1. Assure us that the code is behaving correctly.
2. Allow us to refactor with confidence.
3. Help us write more maintainable code.

A process to help you write tests that achieve these goals

1. Choose the part of the code you want to test (a class, a group of classes, the full end to end stack). For functional tests, try and pick a group that is at the same "level", or that achieve an isolated unit of work that makes sense as a standalone function.
2. Draw a mental box around the classes that will be in the test. Everything inside that box should be able to be completely refactored (methods renamed, classes renamed, code moved around) without breaking this test. Only mock or stub or test calls to things at the edges of the box.

bethesque

1. Identify the steps in the high level process

   eg.

   • Step 1: Download CSV files from box
   • Step 2: Convert CSV to JSON
   • Step 3: Upload JSON and CSV files to S3

2. Create modules for each of those steps. In our use case, the top level process matches a pattern called "ETL" or "Extract, Transform, Load", so we used those names.