The answer is remarkably simple, but non-obvious: namespaces.

Prerequisites

For this approach to work, the assumptions are:

• Your code emitting headers and output lives in a namespace other than the global namespace.

That's it. Considering that most PHP code you grab anymore does this, and most coding standards you run across will require this, it's a safe bet that you're already ready. If you're not, go refactor your code now, before continuing; you'll thank me later.

The technique

PHP introduced namespaces in PHP 5.3. Namespaces cover classes, as most of us are well aware, but they also cover constants and functions — a fact often overlooked, as before 5.6 (releasing next week!), you cannot import them via use statements!

That does not mean they cannot be defined and used, however — it just means that you need to manually import them, typically via a require or require_once statement. These are usually anathema in libraries, but for testing, they work just fine.

Here's an approach I took recently. I created a file that lives — this is the important bit, so pay attention — in the same namespace as the code emitting headers and output. This file defines several functions that live in the global (aka PHP's built-in) namespace, and an accumulator static object I can then use in my tests for assertions. Here's what it looks like:

namespace Some\Project;

abstract class Output
{
    public static $headers = array();
    public static $body;

    public static function reset()
    {
        self::$headers = array();
        self::$body = null;
    }
}

function headers_sent()
{
    return false;
}

function header($value)
{
    Output::$headers[] = $value;
}

function printf($text)
{
    Output::$body .= $text;
}

A few notes:

• headers_sent() always returns false here, as most emitters test for a boolean true value and bail early when that occurs.
• I used printf() here, as echo cannot be overridden due to being a PHP language construct and not an actual function. As such, if you use this technique, you will have to likely alter your emitter to call printf() instead of echo. The benefits, however, are worth it.
• I marked Output abstract, to prevent instantiation; it should only be used statically.

I place the above file within my test suite, usually under a TestAsset directory adjacent to the test itself; since it contains functions, I'll name the file Functions.php as well. This combination typically will prevent it from being autoloaded in any way, as the test directory will often not have autoloading defined, or will be under a separate namespace.

Inside your PHPUnit test suite, then, you would do the following:

namespace SomeTest\Project;

use PHPUnit_Framework_TestCase as TestCase;
use Some\Project\FrontController;
use Some\Project\Output;                 // <-- our Output class from above
require_once __DIR__ . '/TestAsset/Functions.php'; // <-- get our functions

class FrontControllerTest extends TestCase
{
    public function setUp()
    {
        Output::reset();
        /* ... */
    }

    public function tearDown()
    {
        Output::reset();
        /* ... */
    }
}

From here, you test as normal — but when you invoke methods that will cause headers or content to emit, you can now test to see what those contain:

    public function testEmitsExpectedHeadersAndContent()
    {
        /* ... */

        $this->assertContains('Content-Type: application/json', Output::$headers);
        $json = Output::$body;
        $data = json_decode($json, true);
        $this->assertArrayHasKey('foo', $data);
        $this->assertEquals('bar', $data['foo']);
    }

How it works

Why does this work?

PHP performs some magic when it resolves functions. With classes, it looks for a matching class either in the current namespace, or one that was imported (and potentially aliased); if a match is not found, it stops, and raises an error. With functions, however, it looks first in the current namespace, and if it isn't found, then looks in the global namespace. This last part is key — it means that if you redefine a function in the current namespace, it will be used in lieu of the original function defined by PHP. This also means that any code operating in the same namespace as the function — even if defined in another file — will use that function.

This technique just leverages this fact.

Testing Code That Emits Output was originally published 21 August 2014 on https://mwop.net by Matthew Weier O'Phinney.

PHPUnit offers a variety of methods for setting up test suites, some trivial and some complex. The Zend Framework test suite, for instance, goes for a more complex route, adding component-level suites that require a fair amount of initial setup, but which allow us fairly fine-grained control.

However, testing and test automation should be easy and the complex approach is overkill for most of our applications. Fortunately, PHPUnit offers some other methods that make doing so relatively simple. The easiest method is to use an XML configuration file.

As an example, consider the following:

<phpunit>
    <testsuite name="My Test Suite">
        <directory>./</directory>
    </testsuite>

    <filter>
        <whitelist>
            <directory suffix=".php">../library/</directory>
            <directory suffix=".php">../application/</directory>
            <exclude>
                <directory suffix=".phtml">../application/</directory>
            </exclude>
        </whitelist>
    </filter>

    <logging>
        <log type="coverage-html" target="./log/report" charset="UTF-8"
            yui="true" highlight="true"
            lowUpperBound="50" highLowerBound="80"/>
        <log type="testdox-html" target="./log/testdox.html" />
    </logging>
</phpunit>

First thing to note, relative paths are relative to the configuration file. This allows you to run your tests from anywhere in your tests tree. Second, providing a directory directive to the testsuite directive scans for all files ending in Test.php in that directory, meaning you don't have to keep a list of your test cases manually. It's a great way to automate the suite. Third, the filter directive allows us to determine what classes to include and/or exclude from coverage reports. Finally, the logging directive lets us specify what kinds of logs to create and where.

Drop the above into tests/phpunit.xml in your application, and you can start writing test cases and running the suite immediately, using the following command:

$ phpunit --configuration phpunit.xml

I like to group my test cases by type. I have controllers, models, and often library code, and need to keep the tests organized both on the filesystem as well as for running the actual tests. There are two things I do to facilitate this.

First, I create directories. For instance, I have the following hierarchy in my test suite:

tests/
    phpunit.xml
    TestHelper.php
    controllers/
        IndexControllerTest.php (contains IndexControllerTest)
        ErrorControllerTest.php (contains ErrorControllerTest)
        ...
    models/
        PasteTest.php           (contains PasteTest)
        DbTable/
            PasteTest.php       (contains DbTable_PasteTest)
        ...
    My/
        Form/
            Element/
                SimpleTextareaTest.php

controllers/ contains my controllers, models/ contains my models. If I were developing a modular application, I'd have something like blog/controllers/ instead. Library code is given the same hierarchy as is found in my library/ directory.

Second, I use docblock annotations to group my tests. I add the following to my class-level docblock in my controller test cases:

/**
 * @group Controllers
 */

Models get the annotation @group Models, etc. This allows me to run individual sets of tests on demand:

$ phpunit --configuration phpunit.xml --group=Controllers

You can specify multiple @group annotations, which means you can separate tests into modules, issue report identifiers, etc; additionally, you can add the annotations to individual test methods themselves to have really fine-grained test running capabilities.

Astute readers will have noticed the TestHelper.php file in that directory listing earlier, and will be wondering what that's all about.

A test suite needs some environmental information, just like your application does. It may need a default database adapter, altered include_paths, autoloading set up, and more. Here's what my TestHelper.php looks like:

<?php
/*
 * Start output buffering
 */
ob_start();

/*
 * Set error reporting to the level to which code must comply.
 */
error_reporting( E_ALL | E_STRICT );

/*
 * Set default timezone
 */
date_default_timezone_set('GMT');

/*
 * Testing environment
 */
define('APPLICATION_ENV', 'testing');

/*
 * Determine the root, library, tests, and models directories
 */
$root        = realpath(dirname(__FILE__) . '/../');
$library     = $root . '/library';
$tests       = $root . '/tests';
$models      = $root . '/application/models';
$controllers = $root . '/application/controllers';

/*
 * Prepend the library/, tests/, and models/ directories to the
 * include_path. This allows the tests to run out of the box.
 */
$path = array(
    $models,
    $library,
    $tests,
    get_include_path()
);
set_include_path(implode(PATH_SEPARATOR, $path));

/**
 * Register autoloader
 */
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();

/**
 * Store application root in registry
 */
Zend_Registry::set('testRoot', $root);
Zend_Registry::set('testBootstrap', $root . '/application/bootstrap.php');

/*
 * Unset global variables that are no longer needed.
 */
unset($root, $library, $models, $controllers, $tests, $path);

The above ensures that my APPLICATION_ENV constant is set appropriately, that error reporting is appropriate for tests (i.e., I want to see all errors), and that autoloading is enabled. Additionally, I place a couple items in my registry — the bootstrap and test root directory.

In each test case file, I then do a require_once on this file. In future versions of PHPUnit, you'll be able to specify a bootstrap file in your configuration XML that gets pulled in for each test case, and you'll be able to even further automate your testing environment setup.

Hopefully this will get you started with your application testing; what are you waiting for?

Setting up your Zend_Test test suites was originally published 11 September 2008 on https://mwop.net by Matthew Weier O'Phinney.