The first PHPUnit test on code that was never designed for it

The honest starting position on a codebase written before anyone here wrote tests is that most of it cannot be instantiated. Constructors open database connections, classes read $_POST directly, and the interesting logic is in a four-hundred-line function in a file that also emits HTML. The first test is therefore not for the important thing. It is for whatever can be reached without changing a line.

class VatTest extends PHPUnit_Framework_TestCase
{
    public function setUp()
    {
        require_once __DIR__ . '/../application/helpers/vat_helper.php';
    }

    public function testStandardRateIsAppliedToNetPrice()
    {
        $this->assertEquals(11800, vat_gross(10000, 'TR'));
    }

    public function testUnknownCountryIsTreatedAsZeroRated()
    {
        $this->assertEquals(10000, vat_gross(10000, 'XX'));
    }
}

Two functions out of forty thousand lines is not coverage and there is no point pretending otherwise. What it buys is infrastructure: the project now has a phpunit.xml, a bootstrap, and a command that exits zero or does not, so the second test costs ten minutes rather than the afternoon the first one did. Choose the target by looking for what is already pure — a rate calculation, a formatter, a validator, a slug generator. Anything else needs its dependencies pulled out of the constructor first, and refactoring under a test you cannot yet write is exactly the manoeuvre to avoid. The cost worth naming out loud is that a suite covering only the easy parts is a green build that proves very little, and green builds are persuasive. Write down what is not covered, somewhere the next person will read it, or the number of tests becomes an argument in a discussion it has no business being in.