Proposal: Consumer Actors

[maxlinc]

Consumer Actor Adapter

The roadmap for Pacto v0.4.0 will shift towards a more hexagonal or "Ports and Adapters" architecture. One of my planned adapters is Actors - in the sense of "courtroom re-enactments".

The Consumer Actor adaptor type will drive the consumer during testing.

Responsibility

The Consumer Actor is responsible for creating a request for Pacto to validate. Since the creation of a request kicks off the test workflow, this adapter is fairly open ended. It converts something into a Pacto Request, but the type of something will probably vary with each Consumer Actor.

We already have three likely candidates for Consumer Actors:

• [x] JSONGeneratorConsumerActor - creates a request based on the JSON schema. This is current behavior used by the validate rake task
• [x] ExampleConsumerActor - Creates a request based on an example. I propose this as the new default behavior for the validate rake task in v0.4.0, taking advantage of the example section of the new Contract schema.
• [ ] WebMockConsumerActor - Forwards a request detected via WebMock to Pacto. This is usually used when driving tests via RSpec. See the WebMockAdapter.
• [ ] ProxyConsumerActor - Forwards a request received by a server to Pacto. This, combined with the WebMockConsumerActor, is how the Pacto Server works.

  Proposed Adapter Interface

# Generates a request for the service described by the contract
# @param contract [Pacto::Contract] the contract describing the service.
# @params data [Object] data to convert to a request (expected type varies by actor)
# @return [Request]
def reenact(contract, data)
  # Do stuff
end

I think the returned type can be a Faraday::Request. There is an argument for having a Pacto::Request class for encapsulation, but Faraday::Request a generic HTTP interface that supports many HTTP libraries, and having concepts of both Pacto::Request and Pacto::RequestClause has caused confusion in the past. So I support Faraday::* for objects representing real HTTP transactions, and Pacto::* for abstract definitions and rules for those transactions.

Proposed Port Locations

The main location where this needs to be plugged in is RequestClause#execute.

There should be a default Consumer Actor class set at either the Pacto::Configuration or perhaps as part of each "prosecutor" that drives validation (e.g. the rake, rspec, or pacto-server APIs).

[maxlinc]

ExampleConsumerActor was fixed by #118.

I'm not 100% sure WebMockConsumerActor and ProxyConsumerActor make sense. Right now those are setup as "Adapters" rather than Actors. So... closing.