Closed jskirst closed 7 years ago
I would limit this to each scenario. It makes sense to carry headers over a series of requests, but a new scenario should start afresh. If one wants to set default headers for a bunch of scenarios, one can use background steps for that. Or if one wants to set default headers for ALL scenarios, a scenario hook can do so. The point is we should still allow more fine grained control over this.
I would also propose to expose a step definition to set default headers, or else one has to dig into ruby to do so. And we should have a scenario hook that auto resets any set default headers after each scenario to prevent misuse of this.
Also it would be great if you can add a sample (to features/sample.feature
) to demonstrate how to set default headers. The build runs against this sample to validate if anything is breaking.
@hidroh Sure! Agree with your approach - though I think this should be settable as well from a Background block. Opened a branch on my side to fulfill the immediate need, but I'll work on it and bring it inline with your comments.
Will re-open PR when branch is ready. May be a while.
Instead of being assigned to
nil
,@headers
are now assigned to adefault_headers_or_hash
method that checks to see if a user provideddefault_headers
method has been defined and returns that, or returns empty hash.