You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 5, 2019. It is now read-only.
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]defreenact(contract,data)# Do stuffend
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.
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).
The text was updated successfully, but these errors were encountered:
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:
Proposed Adapter Interface
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).
The text was updated successfully, but these errors were encountered: