-- till <[email protected]> wrote
(on Wednesday, 18 March 2009, 03:13 PM +0100):
> On Wed, Mar 18, 2009 at 2:48 PM, Matthew Weier O'Phinney
> <[email protected]> wrote:
> > -- till <[email protected]> wrote
> > (on Wednesday, 18 March 2009, 12:35 PM +0100):
> > > On Tue, Mar 17, 2009 at 7:25 PM, Matthew Weier O'Phinney
> > > <[email protected]> wrote:
> > > > -- till <[email protected]> wrote
> > > > (on Tuesday, 17 March 2009, 05:21 PM +0100):
> >
> > <snip>
> >
> > > The other thing I noticed was that it did in my ErrorController too (I
> > > tested it -- e.g. url does not exist, assert the status code is 404),
> > > but I am using setRawHeader() there.
> > >
> > > I'll give you a hopefully more detailed example:
> > >
> > > /**
> > > * Renders the response
> > > *
> > > * @param Zend_Controller_Response_Abstract $response - The response
> > > object
> > > * @return void
> > > */
> > > public function render(Zend_Controller_Response_Abstract $response)
> > > {
> > > $response->setHeader('Content-Type', 'text/html; charset=utf-8',
> > > true);
> > > $response->setHeader('P3P', 'policyref="/w3c/p3p.xml",CP="NOI
> > > DSP COR NID CURi DEVa OUR NOR"', true);
> > >
> > > $response->sendHeaders();
> > > $response->outputBody();
> >
> > These are the problem right here. Zend_Test makes the assumption that
> > the front controller's dispatch() method is the only place that sends
> > headers and content back to the client; it can then take advantage of
> > the returnResponse front controller setting to prevent that from
> > happening, which then lets you make assertions against what the response
> > object contains.
> >
> > So, the moral of the story: never send headers and output manually if
> > you want to test your controllers.
>
> I still don't understand -- sorry, maybe I am super-slow. How or
> where do I set the header correctly? I need the p3p privacy policy,
> etc..
>
> Also, my ErrorController forces a 404 response or a 500 when there's
> an issue. I gather this is "not allowed" either, or what do you
> propose?
Please read carefully what I said above. The issue is that you're
calling the response object's sendHeaders() and outputBody() methods
directly in userland code. Setting headers using the response object is
fine as long as you don't then send them manually.
> > <snip>
> >
> > > I've discovered the Zend_Session::$_unitTestEnabled flag, but why I am
> > > asking is, that, e.g. my tearDown() looks like this:
> > >
> > > public function tearDown()
> > > {
> > > Zend_Session::namespaceUnset('fooSession');
> > > Zend_Session::expireSessionCookie();
> > > Zend_Session::stop();
> > > Zend_Session::destroy(true);
> > >
> > > unset($this->bootstrap);
> > > }
> > >
> > > Yet, all consecutive tests fail because it says:
> > > Zend_Session_Exception: A session namespace object already exists for
> > > this namespace ('fooSession'), and no additional accessors (session
> > > namespace objects) for this namespace are permitted.
> > >
> > > I'm opening fooSession in my bootstrap, but from what I gather my
> > > tearDown() doesn't get rid off everything.
> > >
> > > That's another thing I've been wrestling with. ;-)
> >
> > Get rid of your tearDown() method. The bootstrap() method calls reset(),
> > which resets the $_SESSION superglobal as well as Zend_Session. What
> > you've done in your tearDown() is redundant.
> >
> > What happens if you remove it?
>
> Well, nothing -- the error stays. I've tried all kind of things in
> "tearDown()" because I got the error about the namespace. I wouldn't
> mind getting rid off it if it worked without it.
Are you calling dispatch() multiple times in the same method by any
chance?
--
Matthew Weier O'Phinney
Software Architect | [email protected]
Zend Framework | http://framework.zend.com/
