Expose the response object

[christeredvartsen]

This PR adds a getResponse() method to the Behat\WebApiExtension\Context\WebApiContext class so that classes extending this can access the response instance. Will solve #45.

I have a context class that adds some @Given/@When/@Then that uses the response instance that uses the code added in this PR as well.

[stof]

a getter with a mixed returned type makes it quite hard to use IMO

[christeredvartsen]

I'm not sure why \GuzzleHttp\Message\ResponseInterface is mentioned anyways. That interface does not exist in the version of Guzzle that is installed when doing a simple composer install after cloning this project. The guzzle response (GuzzleHttp\Psr7\Response) that is being used implements Psr\Http\Message\ResponseInterface, so it might very well be that the first part of the existing @var hint is obsolete?

[stof]

@christeredvartsen We support both guzzle 5 and guzzle 6. the version being installed depends on your PHP version and on other constraints in the project (some other package may be incompatible with Guzzle 6). this is why the response property can have 2 different types

[christeredvartsen]

OK. The other way to make the response instance available for sub classes is to make it protected, but that does not seem like a better / worse solution to me.

[SebastienTainon]

I think the response should be exposed too @stof

Here's an example: I want to check that the response matches some pattern without reimplementing all the iSendARequestWith... functions.

How can I do this? My opinion is that I can extend your WebApiContext and add a new function like theResponseShouldMatchCustomPattern but in this function I need the response from the WebApiContext, however I can't access it because it is private.

Do you have a solution for this? I think exposing the response either way would make everything easier.

[lossendae]

Hello,

I just encountered the same issue where I wanted to check a specific key for JSON response array in my FeatureContext but can't access the response property.

Is there a good reason why those methods and properties visibility where set to private ?

[mkosiedowski]

Any news on this pull request? I would also like to have response object visible in sub classes so I can write more detailed tests

[douglaslinsmeyer]

+1, Same as @lossendae

[fabamatic]

+1 You are shooting yourself in the foot by not making the response accesible. My tests are complex and require data from the response.

[theweekendgeek]

+1, I came across this today as I wanted to extend the WebApiContext with some custom functions