bethesque

require 'date'

class Applicant
  attr_accessor :date
end

applicant = Applicant.new
applicant.date = Date.new(2014, 10, 13)

require 'reform'

bethesque

PactBroker::Client::PacticipantDocumentationTask.new do | pacticipant |
  pacticipant.repository git: 'git@github.com/bethesque/some-consumer'
  pacticipant.doc 'http://github.com/bethesque/some-consumer'
end

bethesque

module['exports'] = function echoHttp (hook) {

  hook.debug("Debug messages are sent to the debug console");

  hook.debug(hook.params);

  hook.debug(hook.req.path);

  hook.debug(hook.req.method);
  

bethesque

require 'representable'
require 'representable/json'
require 'ostruct'
require 'json'
require 'hashie'

json = {
  person: {
    name: 'Beth',
    surname: 'Someone'

bethesque

class ProxyApp
  
  def initialize real_app
    @real_app = real_app
  end
  
  def call env
    @real_app.call(env.merge('HTTP_AUTHORIZATION' => '12345'))
  end
end

bethesque

require 'minitest/autorun'
require 'date'
require 'reform' #  1.2.2

Person = Struct.new(:date_of_birth)

class DateForm < Reform::Form
  property :day
  property :month
  property :year

bethesque

class Action
  
  def self.call parameter
    new(parameter).call
  end
  
  def initialize parameter
    @parameter = parameter
  end
  

bethesque

An idea: Set up an interaction for a unit test (using strict, exact matching), but specify that it can be used for stubbing in a later test, and specify the route that it should be matched against (with optional tags?). The Mock Server would write these interactions to a separate file, or add metadata to them in the normal pact file. Then, during an integration test, interactions can be loaded and will act as stubs using "type based" matching (something_like).

This means that our stubs will be verified as well as our mocks.

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.

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.