-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending a Pact #84
Comments
It's something we've thought about, but have always managed to find a way to work around. I'm a little hesitant to add it, but can see why it would be useful. How are you verifying the provider at the moment? Using pact-provider-proxy to verify against a running server, or running it against a normal Rack app? |
We're running against a normal Rack app. On Mon, Jul 20, 2015 at 6:45 PM, Beth Skurrie notifications@github.com
|
In that case, you can do a quick and dirty trick using some Rack middleware. class ProxyRackApp
def initialize app
@app = app
end
def call env
# Modify headers here!
@app.call(env)
end
end Pact.service_provider "My provider" do
app { ProxyRackApp.new(your_provider_app) }
end |
Closing, assuming this helped. |
We're using pact to allow our mobile app development team to define their expectations of our API; they're creating JSON-based pacts via the Swift consumer library. The problem is that our API uses token-based authentication, which works off of request headers (which are fixed in the JSON files).
Would it be possible to extend a pact programmatically so as to allow for more realistic end-to-end testing (without stubbing out the backend)? I would imagine the API would look something like so:
The text was updated successfully, but these errors were encountered: