Multiple dispatch in controller test leads to false Location header

[David Daniel]

Hi there

I have a problem with controller test cases and I think this is a
general problem. It may be that I am totally wrong, however it would be
great if someone could help me sort this out.

When dispatching multiple times within a controller test case, the
assertion about the redirection might lead to a wrong result.

In my case I have to login before I can dispatch the tested controller,
the tested action  is only accessible by an authenticated and authorized
user.

In order to be able to send a form that validates, I dispatch the action
by a _GET_ request, get the _csrf_ token and dispatch the action again
with a _POST_ request - all after logging in first.

Login works and the _GET_ request of the tested action works as well, I
am able to read the csrf token from the response. I am positive that the
post request works as well (I can verify the creation of a new item in
the testing database).

The last issued request (post request) finally redirects to a specific
location. This works when doing this with the browser. If done in a
controller test case, the assertion about the location header fails with
the reason that the effective redirection is taking place to "/" instead
to the specific route.

The header with the correct location is present, that can be verified by
investiating the actual response. In fact the method
=toString()= of the headers gives a different result than accessing the
location header directly:

$headers = $this->getApplication ()->getResponse ()->getHeaders ();
...
var_dump ($headers->toString ());
// leads to:
string(41) "Location: /pres/pharmacy/edit/1
"
...
var_dump ($headers->get ('location'));
// leads to:
class Zend\Http\Header\Location#3642 (1) {
  protected $uri =>
  class Zend\Uri\Uri#3869 (8) {
    protected $scheme =>
    NULL
    protected $userInfo =>
    NULL
    protected $host =>
    NULL
    protected $port =>
    NULL
    protected $path =>
    string(1) "/"
    protected $query =>
    NULL
    protected $fragment =>
    NULL
    protected $validHostTypes =>
    int(31)
  }
}

Now the test fails:

Failed asserting response redirects to "/pres/pharmacy/edit/1", actual
redirection is "/"

I am not sure if multiple dispatching within controller tests is
something that is not supposed to work. If this was the case, I would
need to refactor about the entire application, complicating things
heavily - I would need to modify the entire authentication stack, modify
the creation of all forms and so on - everything in order to be able to
test the application. I hope there is another answer to this...

Big thanks in advance!
Greets
dave


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Daniel]

Hi again

The missing interest in this question tells me something...

I finally managed the problem to disappear by not (probably stupidly)
logging in by dispatching the login controller. In test cases I use the
login mechanism "directly" by using the authentication service. Now its
possible dispatch a controller multiple times successfully.

Sorry for the disturbance and thanks for your effort making the
framework better.

Sincerely
Dave

Am 30.05.2014 11:49, schrieb David Daniel:

> Hi there
>
> I have a problem with controller test cases and I think this is a
> general problem. It may be that I am totally wrong, however it would be
> great if someone could help me sort this out.
>
> When dispatching multiple times within a controller test case, the
> assertion about the redirection might lead to a wrong result.
>
> In my case I have to login before I can dispatch the tested controller,
> the tested action  is only accessible by an authenticated and authorized
> user.
>
> In order to be able to send a form that validates, I dispatch the action
> by a _GET_ request, get the _csrf_ token and dispatch the action again
> with a _POST_ request - all after logging in first.
>
> Login works and the _GET_ request of the tested action works as well, I
> am able to read the csrf token from the response. I am positive that the
> post request works as well (I can verify the creation of a new item in
> the testing database).
>
> The last issued request (post request) finally redirects to a specific
> location. This works when doing this with the browser. If done in a
> controller test case, the assertion about the location header fails with
> the reason that the effective redirection is taking place to "/" instead
> to the specific route.
>
> The header with the correct location is present, that can be verified by
> investiating the actual response. In fact the method
> =toString()= of the headers gives a different result than accessing the
> location header directly:
>
> $headers = $this->getApplication ()->getResponse ()->getHeaders ();
> ...
> var_dump ($headers->toString ());
> // leads to:
> string(41) "Location: /pres/pharmacy/edit/1
> "
> ...
> var_dump ($headers->get ('location'));
> // leads to:
> class Zend\Http\Header\Location#3642 (1) {
>   protected $uri =>
>   class Zend\Uri\Uri#3869 (8) {
>     protected $scheme =>
>     NULL
>     protected $userInfo =>
>     NULL
>     protected $host =>
>     NULL
>     protected $port =>
>     NULL
>     protected $path =>
>     string(1) "/"
>     protected $query =>
>     NULL
>     protected $fragment =>
>     NULL
>     protected $validHostTypes =>
>     int(31)
>   }
> }
>
> Now the test fails:
>
> Failed asserting response redirects to "/pres/pharmacy/edit/1", actual
> redirection is "/"
>
> I am not sure if multiple dispatching within controller tests is
> something that is not supposed to work. If this was the case, I would
> need to refactor about the entire application, complicating things
> heavily - I would need to modify the entire authentication stack, modify
> the creation of all forms and so on - everything in order to be able to
> test the application. I hope there is another answer to this...
>
> Big thanks in advance!
> Greets
> dave
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]