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.

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.

How do we implement it

We need build automation.

You start by identifying repetitive processes (running tests, analyzing source code, packaging, deployment). You want to make these processes a non-event.

Static code analysis

Lines of code gives a text-based metric for code size.

• Lines of code (loc)
• comment lines of code (cloc)
• non-comment lines of code (ncloc)
• executable lines of code (eloc)

Code duplication. Is it textually identical? token for token identical? functionally identical? Dupicate code contradicts code reuse. Co-Evolution of clones hinders maintenance. There is a tool called PHPCPD (a copy-paste detector). Highest they've seen is 16% duplication in a code base of 5 million lines of code.

code complexity

Cyclomatic complexity counts the number of branching points such as if, for,foreach,while,case,catch,&&,"",ternary operatory. NPath Complexity counts the number of execution paths. Higher complexity leads to more errors and makes testing harder.

You can analyze code with "sniffs".

build automation

• apache ant
• gnu make
• phing
• rake
• shell scripts

Reviewing some of the tools that got covered in another talk I blogged about. If anything new/interesting is added, i'll list it. @s_bergmann recommends Hudson (http://hudson-ci.org). Apparently very easy to use and is used by some big names like Sun.

Related articles by Zemanta

• PHP Code Review (slideshare.net)
• Continuous Integration of PHP Projects (slideshare.net)
• Applied Lean Startup Ideas: Continuous Deployment at kaChing (slideshare.net)
• How can you improve, harmonize and automate your development process using tools like Maven, Hudson, and Nexus? This presentation is a high-level overview of Java software development process improvement. (slideshare.net)

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.