I found a link for a PhpUnit tutorial:
http://www.phppatterns.com/index.php/ar ... ew/33/1/2/.
For SimpleTest (note I haven't run this through the parser):
Code: Select all
###runner code
require_once('path/to/config.php'); // define SIMPLE_TEST & anything else you need for tests here
require_once(SIMPLE_TEST . 'unit_tester.php');
require_once(SIMPLE_TEST . 'reporter.php');
###
require_once('path_to/Render.php');
class TestOfRender extends UnitTestCase
{
function TestOfRender()
{
$this->UnitTestCase();
}
function testRenderText()
{
$string = 'foo';
$render =& new Render;
ob_start();
$this->assertIdentical($render->renderText($string), true);
$this->assertEqual(ob_get_contents(), $string . '<br />');
ob_end_clean();
}
}
###runner code
$test =& new TestOfRender();
$test->run(new HtmlReporter());
###
Careful with assertIdentical() and assertEqual() - latter doesn't check type. I didn't actually need to use assertIdentical() here. That's actually an important testing mistake worth mentioning: never test for anything more than you really need. If you do, alternative implementations which satisfy all the real requirements might fail the test and that hampers progress when you are refactoring.
The runner code doesn't usually go in the test. The reason for this is that you will want to group tests: an "all tests" group which runs everything, maybe various smaller groups, and finally something which runs a single test itself. When you're working on a new class, you'd be striving for the green bar with the single test. Then, when it's working, you'd run "all tests" to make sure it isn't breaking anything else. If you had to run them all individually (there could be hundreds) you wouldn't do it very often - if at all - but if you can easily run all tests each time you've edited a class you will.
With frequent "all tests" runs, you can quickly spot class interaction problems while they are still relatively easy to fix. If you waited a month between checks, there could be all kinds of bugs reinforcing and obscuring each other. The same holds true on a smaller scale, in individual tests. If you are editing a class, run its test regularly after every minor edit to check it hasn't been broken. Tests are a wonderful way to keep you on the straight and narrow and can save a lot of time spent in debugging hell.
You'll also find that they lead you to think more carefully about the behaviour of the class you're working on resulting in more robust code.
http://www.martinfowler.com/articles/co ... ation.html