Internet Strategy Guide

Note: I have tested this in PHPUnit 3.4.1 and haven't tried it out in 3.5.
Anyone who has worked with PHPUnit has most likely worked with expected exceptions and mock objects. The nice thing about working with expected exceptions is that we have access to a handy @expectedException annotation. I've gotten into the habit of using this for exceptions my fixtures should throw but also for when I'm using a mock object to verify a method call. So my tests usually expect foo_exception for fixture throws and when i'm testing method calls via a mock, they expect Exception. Therein lies my problem. Because all my custom class exceptions obviously extend the Exception class, I can get some false positives in testing.

equire_once 'Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
require_once('foo.php');
class tmpTest extends PHPUnit_Framework_Testcase
{
 
    /**
     * @expectedException Exception
     */
    public function testFooBar()
    {
        $foo=new foo();
        $foo->bar();
    }
 
    /**
     * @expectedException Exception
     */
    public function testBarBaz()
    {
        $mock=$this->getMock('foo',array('baz'));
        $mock->expects($this->any())
         ->method('baz')
         ->will($this->throwException(new Exception('baz')));
        $mock->barbaz();
    }
}

class foo_exception extends Exception{}
 
class foo
{
    public function bar()
    {
        throw new foo_exception('bar');
    }
 
    public function baz()
    {
        echo "bwah\n";
    }
 
    public function barbaz()
    {
        $this->bar();
        $this->baz();
    }
}

So here we have an expectation for Exception but if we look at the code, we see that the bar method throws a foo_exception and the testBarBaz test is trying to test for the baz call via a mock that throws an Exception. if we change the annotation to expect foo_exception, the test still passes. This leads me to believe the best way to isolate the behavior we wish to test is to not use annotation for these sorts of tests. Or if you want to use annotation, be sure to use a unique exception for the mock. This means, unfortunately for me, that I'll have to go back through all my tests and ensure there's no false positives.

Lesson learned: be careful using shortcuts (and don't stand in the fire).

On a side note, this part of PHPUnit is why those tests will behave that way. The behavior is completely my fault but I wanted to confirm it was behaving because of how it was verifying the expected exception.

"Countinous Integration is about preventing your developers from burning in Integration Hell" - @s_bergmann

Integration Hell

My code is perfect, yours is pretty good and then Martin...well, he's a fucking idiot. (lost where he was going with this story). D=

Team member should integrate their work frequently. This reduces errors when managing multiple team members. The value (ROI) is in:

• reducing risk
• reduce repetitive processes
• generate deployable software
• enable better project visibility
• establish greater product confidence
• helps with late discovery of defects
  • regression testing
  • test coverage
• prevents low quality software
  • coding standard adherance
• prevents lack of deployable software

This practice focuses on software design that uses unit tests to prevent and detect defects. This all significantly works to provide significantly better quality software.

(continue reading...)

While the manual for Zend_Session does discuss unit testing and the read-only exception, it has no mention of an exception I encountered recently while unit testing. I admit that the reason I encountered the exception is most likely because I'm Doing It Wrong. However, given reality, I did not have time to properly make the class, or at least do it better. I received the following exception:

exception 'Zend_Session_Exception' with message 'Session must be started before any output has been sent to the browser; output started...'

The problem was, of course, that the feedback from previous tests was already outputted to the screen. I could've solved this by playing with my test suite and just starting sessions at that level but that wouldn't have been the best solution. In fact, I'd qualify that solution under bandaids (solutions that mask a problem instead of fixing them). If you can't see why it is a bandaid, I'm happy to discuss it but for once, I"m going to try to stay on topic and not digress any further than I have.

So, here's the scenario:

• not enough time to refactor the class so that sessions are only called/created when necessary
• sessions are being called because we're testing some auth stuff which relies on session information, we might not be able to do DI (see above)
• we want to minimize contributing factors to test failure so session has to be called/destroyed for the tests that need it, all other tests should never have session existing

The solution? A little 'undocumented' static variable:

Zend_Session::$_unitTestEnabled = true;

Ok, undocumented is a bit misleading. You won't find out about it by looking at the Manual but will find it when you're digging through the API. So it is documented, just not well. I'm guessing because it is rare to encounter the exception. I'm not surprised that I encountered it since my projects always seem to have some degree of weirdness, which makes for an interesting learning curve thats compounded with Zend's curve.