ZF-4511: Zend_Test_PHPUnit_ControllerTestCase::resetResponse() does not allow a new clean dispatch

Issue Type: Improvement Created: 2008-10-07T10:04:56.000+0000 Last Updated: 2009-09-17T11:00:05.000+0000 Status: Resolved Fix version(s): - 1.9.3 (22/Sep/09)

Reporter: Giorgio Sironi (giorgiosironi) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Test_PHPUnit

Related issues: Attachments: - ControllerTestCase.patch


After calling a dispatch() in a test, the resetResponse() method cleans the response object and the registry instance. However, the request object still contains param from the previous dispatch and so it contaminates the new one. I personally call $this->setUp() after every dispatch/assertions cycle to ensure cleanliness. Not sure if it is the intended behaviour, I think reset the request object or provide a parameter of resetResponse() or a resetRequest() method would be useful.


Posted by Travis Pew (travisp) on 2008-10-29T10:05:21.000+0000

I agree that this is an issue and comes up a lot for me in unit testing, especially when param are set during dispatch.

For example: function testCreateAccount() { $this->_login(); //dispatches to /auth/login and logs the user in $this->dispatch('/account/create'); //any param set during the dispatch to /auth/login remain }

This is particularly a problem when an error is thrown and I want to do a second dispatch. The ErrorHandler plugin sets the 'error_handler' param, which in some cases can cause issues.

I therefore think it would make sense to have the following in Zend_Test_PHPUnit_ControllerTestCase to make it clear that this should be called. function resetRequest() { $this->_request = null; return $this; }

It would go along nicely with resetResponse, which according to the PHPdoc is 'Useful for test cases that need to test multiple trips to the server.'

Posted by Matthew Weier O'Phinney (matthew) on 2008-10-29T10:18:49.000+0000

Actually, dispatch() should simply always create a new request and response pair. (I thought I had it doing this already, but it's not.)

Posted by Matthew Weier O'Phinney (matthew) on 2008-11-06T11:22:20.000+0000

Added resetRequest() in r12337 and r12339.

Posted by David Abdemoulaie (hobodave) on 2009-03-11T16:40:18.000+0000

I'm reopening this due to the exact same problem being caused by the super globals being persistent across multiple requests.


In this case, I log my user in with login(), and immediately reset the response and request. Yet, since the $_POST data still contains 'username' and 'password' values, it causes undesired behavior in my changePassword action. Obviously this is easy enough to work around now that I know what's going on. However, it's very misleading to have a resetRequest() that doesn't truly reset the request. The manual even states that these are to be used to simulate multiple requests.

If I submit two forms in a row in my browser, the data from the first doesn't linger and affect the behavior of the second :p.

Posted by Travis Pew (travisp) on 2009-03-11T16:48:18.000+0000

I wanted to add that while there is a resetRequest() function now, the dispatch() function still doesn't seem to actually create the new request and response pair. That is, I still have to call the resetRequest() and resetResponse() before any second dispatch within a single unit test.

And to second what David said, $_POST and $_GET have to be cleared with clearPost() and clearGet(), since the newly created Request object will simply read from these.

Posted by Duo Zheng (duoduo) on 2009-09-16T11:36:58.000+0000

I am with David and Travis.

$_POST and $_GET still persists. The reference guide also gives an example of this to clear POST paramaters:

<pre class="highlight">


The setPost(array()) will not clear anything. resetRequest and resetResponse should handle calling clearPost() and clearGet(). If not at the very least documentation needs to updated also to use $this->request->clearPost(), but it is deceiving that resetRequest actually doesn't fully reset.

Posted by Travis Pew (travisp) on 2009-09-17T10:33:03.000+0000

patch for unit tests for resetRequest() and a proposed patch to fix resetRequest()

the patch to fix resetRequest calls getRequest()->clearQuery(); but it could have just as easily called $_GET = array(); to fix the problem

And I'm unsure if we also want to clear $_REQUEST. Some parts of Zend use it, but there is no method in the request object to clear the _REQUEST superglobal.

Posted by Matthew Weier O'Phinney (matthew) on 2009-09-17T10:49:48.000+0000

My own patch calls both clearQuery() and clearPost() prior to unsetting the request.

Resetting $_REQUEST is not a good idea, as it would also reset cookies -- which likely *should* persist between requests.

My patch will apply shortly.

Posted by Matthew Weier O'Phinney (matthew) on 2009-09-17T11:00:04.000+0000

Fixed in trunk and 1.9 release branch

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.