Skip to content
This repository has been archived by the owner on Dec 5, 2019. It is now read-only.

Proposal: Consumer Actors #114

Closed
2 of 4 tasks
maxlinc opened this issue May 14, 2014 · 1 comment
Closed
2 of 4 tasks

Proposal: Consumer Actors #114

maxlinc opened this issue May 14, 2014 · 1 comment

Comments

@maxlinc
Copy link
Collaborator

maxlinc commented May 14, 2014

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:

  • JSONGeneratorConsumerActor - creates a request based on the JSON schema. This is current behavior used by the validate rake task
  • 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 maxlinc added this to the v0.4.0 milestone May 14, 2014
This was referenced May 14, 2014
@ticolucci ticolucci modified the milestones: v0.3.0, v0.4.0 May 21, 2014
@maxlinc
Copy link
Collaborator Author

maxlinc commented Jul 29, 2014

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants