{
    "href": "/post/2006/01/31/solar-modified-testing-strategy/",
    "relId": "2006/01/31/solar-modified-testing-strategy",
    "title": "Solar: Modified Testing Strategy",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/solar/",
            "relId": "solar",
            "title": "Solar",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2006-02-01 03:57:51 UTC",
    "updated": [
        "2006-02-01 03:57:51 UTC"
    ],
    "html": "<p>In the current release of <a href=\"http://solarphp.com\">Solar</a> (version 0.10.0) I use the <a href=\"http://qa.php.net/write-test.php\">.phpt test format</a>, which is supported very well by <strike>Greg Beaver</strike><ins><a href=\"http://pear.php.net/user/cox/\">Tomas V.V. Cox</a>'s</ins> \"pear run-tests\" code.  The .phpt testing strategy compares the output of a test script to an expected output string, and passes if the outputs match.</p>\n<p>I noticed some time ago that Greg has adopted a testing strategy that combines .phpt with techniques found in <a href=\"http://phpunit.sourceforge.net/\">PHPUnit</a> and <a href=\"http://www.lastcraft.com/simple_test.php\">SimpleTest</a>.  These testing packages use assertions to compare method returns, rather than comparing output at the end of a test script.  Greg's strategy uses assertions within .phpt tests: if there is no output, the test succeeds, but if an assertion fails, it generates unexpected output, which causes the .phpt test to fail.</p>\n<p>(Aside:  While true testing gurus may not think of this as a robust solution [hi <a href=\"http://blog.casey-sweat.us/\">Jason</a>! hi <a href=\"http://www.lastcraft.com/blog/\">Marcus</a>! hi <a href=\"http://www.sebastian-bergmann.de/blog/\">Sebastian</a>!], I have thus far found it to be a \"good-enough\" approach that combines simplicity with ... well, more simplicity.  :-)</p>\n<p>Inspired by Greg's <a href=\"http://cvs.php.net/viewcvs.cgi/pear/PEAR_PackageFileManager/tests/phpt_test.php.inc?view=markup\">PEAR_PHPTest</a> class, I've developed a bare-bones <a href=\"http://solarphp.com/svn/pkg/Solar/Test/Assert.php\">Solar_Test_Assert</a> class that tests assertions and throws PHP5 exceptions on assertion failures.  Add to that <a href=\"http://solarphp.com/svn/pkg/tests/alltests.php\">a quick hack to run all tests at once</a> recursively through subdirectories (courtesy of the \"pear run-tests -r\" switch), and you get a convenient all-at-once testing tool for Solar.  Thanks, Greg, for producing such useful tools.</p>\n<p>I spent one day over the weekend rewriting <a href=\"http://solarphp.com/svn/pkg/tests/\">all the existing Solar tests</a> to use this new strategy, and met with great success.  I did run into one problem, though.  The class-method tests in the subdirectories use a common prepend file.  Normally, you would think that \"include '../prepend.php'\" would work, but because the tests are running at the command line, PHP doesn't include \"..\"  with respect to the subdirectory; instead, it tries to include \"..\" with respect to the current directory.  This is the proper behavior, but it was causing every test to fail.</p>\n<p><a href=\"http://mikenaberezny.com\">Mike Naberezny</a> pointed out a cool trick to work around that behavior; instead of using \"..\", you can use \"dirname(dirname(__FILE__))\" to get to the next-higher directory.  After applying this fix, all my tests ran from the main directory using \"pear run-tests -r\".  Thanks, Mike.</p>\n<p><strong>Update:</strong> (2006-02-01) Greg pointed out that the \"pear run-tests\" is from Tomas V.V. Cox, so I update the above link.  Thanks, Tomas, for this great testing tool.</p>\n"
}