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.

An interesting topic came up in #phpc today. It revolved around some issues I've been encountering in my latest code designs/structures. It also leads into some side topics that I will attempt to explore.

From my point of view, the discussion centered around what is the best 'default' visibility to use for methods. Another thing touched upon is the Open/Closed principle, which I think I subscribe to or may subscribe to(this depends on my ability to determine what half of the words in the entry mean).

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I'm off base in any way.

Methods should only be public when necessary. This is to help reduce the amount of side-effects that can occur because of method overrides.

K, I can accept that and in thinking about my past code, I use to use protected more than private. I used public very sparingly.
Now I find, since I started unit testing, that I have a large amount of public functions than I've had in the past. That is because I can't figure out how to test private methods. One way that I can think of is to create public methods that allow you to test the private ones. Unfortunately, this makes me wonder why the method isn't public to begin with since it seems redundant and wasteful to have these public methods to access private methods.
Please note the key word methods, property accessors are a different story.
The best solution (I can think of) to testing private methods is Mock Objects. Unfortunately, even though I've started to use mocks/doubles more, I'm unsure if my implementation is correct. Until I'm confident in my understanding of mocks/doubles, I worry about having false positives in test results.

Another assertion that was made in the discussion was that private methods allow you to preserve the class' core functionality.
Unfortunately, no matter what the visibility of the method is, you're able to override it (and potentially mess with the core functionality you were trying to preserve).
Example:

class foo{
    private function foobar() {
        echo "foo\n";
        return "foo foo\n";
    }

    public function bar() {
        echo "w00t ";
        return $this->foobar();
    }
}

class bar extends foo{
    private function foobar() {
        return "bar\n";
    }

    public function baz() {
        echo $this->bar();
    }

    public function wut() {
        echo $this->foobar();
    }
}

$f=new bar();
$f->baz();
$f->wut();

By running the above code, you get:

w00t foo
foo foo
bar

If preservation of core functionality is your main concern, then you're better off using final.

So after all that rambling, you're probably wondering what I'm trying to get to. It still comes down to visibility's effect on inheritance. The way I see it, unless you declare the method as final, you can't lock down the parent functionality because private methods can still be overridden. Trying to figure out what level of visibility for a method is a situational call. There is no correct 'default' visibility. Sure private is safer because of least privilege but it makes testing a bear (or at least a bear at my current skill level in testing). Public potentially opens you up for abuse or misuse.

What I would still like to know is, how do you do class method visibility? How does that affect your testing methodology? Can someone give me an example (that isn't a singleton) where private is a better choice over protected? I like protected because it seems less limiting to me and my current coding style appreciates that degree of flexibility.