Research Testing Strategy

[kayvonghaffari]

Consumer-based testing vs Producer-based testing

[kayvonghaffari]

Reasons for having CONSUMERS define their contracts

• In order see what would be needed to remove the old name field, the maintainers could delete it from the response and see which contract tests fail.
• Contract test suites are also valuable when a new service is being defined. Consumers can drive the API design by building a suite of tests that express what they need from the service.
• Consumer services only need to write contracts for aspects of the producing service that are in use

Sources:

• http://martinfowler.com/articles/microservice-testing/#testing-contract-introduction

[kayvonghaffari]

Tools that aid in contract tests

• Pact: https://github.com/realestate-com-au/pact
• Pacto: https://github.com/thoughtworks/pacto
• Janus: https://github.com/gga/janus

[kayvonghaffari]

Questions:

• What if we want to have services using a language other than Ruby in the future?

[roberthoner]

version: 1.0
consumer: api
producer: core

/v1/cards:
  POST:
    With valid card details:
      request:
        body: |
          {
            "card_number": "4111111111111111",
            "exp_month": "08",
            "exp_year": "2017"
          }
      response: 
        code: 200
        body: |
          {
            "token": "CTABCDEFG",
            "exp_month": "08",
            "exp_year": "2017",
            "status": "ready"
          }
    With expired card:
      request:
        body: |
          {
            "card_number": "411111111",
            "exp_month": "01",
            "exp_year": "2000"
          }
      response:
        code: 400
        body: |
          {
            "error": "validation_error",
            "message": "card expired"
          }
/v1/cards/CTabcdef:
  GET:
    With card existing:
      response:
        code: 200
        body: |
          {
            "token": "CTabcdef",
            "status": "ready"
          }
    With non-existing card:
      response:
        code: 404
        body: |
          {
            "error": "validation_error",
            "message": "card not found"
          }
/v1/cards/CTabcdef/credits:
  POST:
    With card existing:
      request:
        body: |
          {
            "amount_cents": 100
          }
      response:
        code: 200
        body: |
          {
            "token": "CCaoeu",
            "amount_cents": 100
          }

# spec/api/do_something_spec.rb
describe '/v1/do_something' do
  context "with something" do
    around { |ex|
      ApiAuthService.with_context("valid credentials") { ex.run }
      CoreService.with_context("With card existing") { ex.run }
    }

    let(:token) { 'CTabcdef' }

    it 'should do something' do
      lookup_card(token)
        CoreService.cards('CTabcdef').get

      process_transaction
        # resp = CoreService
        # authenticate
        #   -> ApiAuthService.api_keys(resp[:token]).get
        # details = CoreService.cards('CTabcdef').get
        # CoreService.cards('CTabcdef').credits!(amount_cents: 100)
    end

  end
end

[kayvonghaffari]

Sharing pacts between consumers and producers: https://github.com/realestate-com-au/pact/wiki/Sharing-pacts-between-consumer-and-provider

[roberthoner]

Our research is done. Closing this out since we've implemented both consumer and producer testing.