> On Tue, Oct 26, 2010 at 9:01 PM, K. Adam Christensen
> <pope@shifteleven.com>wrote:
>
>>
>> I know it's customary for controller unit tests to use the dispatch
>> method, but I think using dispatch goes against writing a unit test.
>> When you use dispatch, you're writing more of an integration test
>> because you end up running though your whole application stack, from
>> bootstrap to front controller and view initialization to finally your
>> controller.
>
>
> As I mentioned the bigger problem is when an exception is unexpectedly
> thrown by a controller. For example, let's say I have a test that verifies
> my login page shows a login form:
>
> public function testLoginPageShowsLoginForm()
> {
> $this->dispatch('login');
> $this->assertQuery('form#login');
> }
>
> If for some reason an exception is thrown, PHPUnit will say "Failed
> asserting node DENOTED BY form#login exists". Unfortunately that message is
> not very useful and I'm left without a clue as to what went wrong. When it
> comes to tests, seeing that exception stack trace is very useful.
>
> If I disable the error handler plugin, the situation is worse -- I'll see a
> message like "Zend_Dom_Exception: Cannot query, no document registered".
>
> Are there any workarounds to providing useful error messages when a
> controller test goes bad?
I totally get why this not reporting the error can be frustrating
because the error message is stuck within the response object; but I
think this better aids what I was saying about creating a UNIT test and
not an INTEGRATION test.
The unit test should help find those nasty exceptions that could pop up
here and there and let you just test the controller as a single unit. I
like leaving the integration tests for selenium/jbehave/cucumber since
that works your browser along with the full server stack.
That's my two cents on the matter
>
>>
>> If you check Zend_Test_PHPUnit_ControllerTestCase.php, you will see that
>> in the dispatch method there (as I am assuming that you're using this
>> method and that your test cases extend from this) that said method sets
>> throwExceptions to true. That appears to be why your settings aren't
>> sticking.
>>
>>
> Thanks, this explains it! I was about to burst a blood vessel in my left eye
> trying to find out why my setting wasn't sticking. Is there a reason why
> exceptions are not allowed to be thrown in controller tests?
Yeah, no idea. It seems kind of weird that it would be set in the
dispatch and not be respected by the test author.
- Adam
没有评论:
发表评论