Unit testing for placeholder-based view-helpers in Zend Framework
Just got bitten by an interesting little issue.
I have a Zend Framework view-helper that I use to add a CSS class to an HTML <body> tag. Usage in a view-script is:
$this->bodyTag()->addClass('someclass');
Then in a layout, I’d output it using:
<?= $this->bodyTag() ?>
The class itself is very simple:
/**
* A body tag
*
* @author David Weinraub <david@papayasoft.com>
*/
class PapayaSoft_Zend_View_Helper_BodyTag extends Zend_View_Helper_Placeholder_Container_Standalone
{
public function bodyTag()
{
return $this;
}
public function toString()
{
$tag = array();
$tag[] = '<body';
$storage = $this->getContainer();
if (count($storage) > 0){
$classes = array();
foreach ($storage as $class){
$classes[] = $class;
}
$tag[] = sprintf(' class="%s"', implode(' ', $classes));
}
$tag[] = '>';
return implode('', $tag);
}
public function addClass($class)
{
$this->getContainer()->append($class);
return $this;
}
}
I’ve begun moving this kind of stuff out into my own library, which I will manage in its own project under source control. I can then import it into multiple projects, just as I would with the libs for Zend or Doctrine or HTML Purifier.
Consequently, it’s now time – actually long past-due – to really get into the discipline of unit-testing. A simple class like this seems a decent place to start.
Unit-tests for the BodyTag class looked something like this:
/**
* Test BodyTag class
*
* @group Zend_View_Helper
* @author David Weinraub <david@papayasoft.com>
*/
class PapayaSoft_Zend_View_Helper_BodyTagTest extends PHPUnit_Framework_TestCase
{
/**
* @var PapayaSoft_Zend_View_Helper_BodyTag
*/
private $_bodyTag;
public function setUp()
{
$this->_bodyTag = new PapayaSoft_Zend_View_Helper_BodyTag();
}
public function tearDown()
{
unset($this->_bodyTag);
}
public function testRenderOnNoAddedClasses()
{
$this->assertEquals('<body>', (string) $this->_bodyTag);
}
public function testRenderOnSingleAddedClass()
{
$this->_bodyTag->addClass('myclass');
$this->assertEquals('<body class="myclass">', (string) $this->_bodyTag);
}
public function testRenderOnMultipleAddedClasses()
{
$this->_bodyTag = new PapayaSoft_Zend_View_Helper_BodyTag();
$this->_bodyTag->addClass('someclass')->addClass('anotherclass');
$this->assertEquals('<body class="someclass anotherclass"<', (string) $this->_bodyTag);
}
}
Pretty straightforward. Or so I thought.
The last test failed, reporting the following:
BodyTagTest::testRenderOnMultipleAddedClasses() Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -<body class="someclass anotherclass"> +<body class="myclass someclass anotherclass">
testRenderOnSingleAddedClass() was still in effect when testRenderOnMultipleAddedClasses() started. When the testRenderOnSingleAddedClass() method is removed, the testRenderOnMultipleAddedClasses() passes.
What’s going on here? The whole point of tearDown() and setUp() is to reset the test environment to a clean state, in this case by unsetting and re-instantiating the $_bodyTag member variable.
Well, the whole key here turns out to be state of the system. It’s not sufficient to simply reset the object in the member variable if it has made other changes to the state of the system. Sort of like selling the cow that crapped in your living room, but forgetting to clean up the mess he made. And that’s actually what appears to be happening.
The framework’s own unit test for Zend_View_Helper_HeadTitle, another Zend_View_Helper_Placeholder_Container_Standalone-extended class, offers some hint of this. The setUp() method is as follows:
/**
* Sets up the fixture, for example, open a network connection.
* This method is called before a test is executed.
*
* @return void
*/
public function setUp()
{
$regKey = Zend_View_Helper_Placeholder_Registry::REGISTRY_KEY;
if (Zend_Registry::isRegistered($regKey)) {
$registry = Zend_Registry::getInstance();
unset($registry[$regKey]);
}
$this->basePath = dirname(__FILE__) . '/_files/modules';
$this->helper = new Zend_View_Helper_HeadTitle();
}
So there is some Zend_Registry stuff in there that needs to be cleared, as well. Adding the registry-clearing code from the ZF unit-test into my own solved the problem.
Live and learn.
