Matthew Weir O'Phinney has been working with PHPUnit and the SPL (Standard PHP Library) in PHP for a bit now, and he's discovered a way to integrate the two to automate the testing procedure.

I've actually come to enjoy the PHPUnit2 style of tests. In the end, I find that my tests are much less verbose than the way I was performing them with phpt, and I tend to test for failure rather than success; failure should be the exception to the rule. The myriad of 'assert' methods make this relatively easy (though some operate in unexpected ways -- try testing assertSame() on two objects that contain PDO handles, for instance).

One thing that was missing for me was an easy way to run all tests in a directory, ala 'pear run-tests'. However, I was initially disappointed. The demonstrated way to do this is to manually require each test file and add the class contained therein to the test suite. Basically, I was going to need to touch the file every time I added a test class to the suite. Bleh!

So, he set about working up his own solution - a regular expresion-based, recursive class that would locate the testing files and perform the specified actions. He shares the solution with a good bit of example code included with the post.

Matthew Weir O'Phinney has been working with PHPUnit and the SPL (Standard PHP Library) in PHP for a bit now, and he's discovered a way to integrate the two to automate the testing procedure.

I've actually come to enjoy the PHPUnit2 style of tests. In the end, I find that my tests are much less verbose than the way I was performing them with phpt, and I tend to test for failure rather than success; failure should be the exception to the rule. The myriad of 'assert' methods make this relatively easy (though some operate in unexpected ways -- try testing assertSame() on two objects that contain PDO handles, for instance).

One thing that was missing for me was an easy way to run all tests in a directory, ala 'pear run-tests'. However, I was initially disappointed. The demonstrated way to do this is to manually require each test file and add the class contained therein to the test suite. Basically, I was going to need to touch the file every time I added a test class to the suite. Bleh!

So, he set about working up his own solution - a regular expresion-based, recursive class that would locate the testing files and perform the specified actions. He shares the solution with a good bit of example code included with the post.

On Christian Stocker's blog today, there's his experience with testing his code coverage visually with the help of the SimpleTest framework.

For our CMS, we use SimpleTest as testing framework. We used it in other projects, and as you should never change a running team, we sticked to that for Flux CMS as well.

But one thing I saw over at PHPUnit2 and badly wanted to have, was the Code-Coverage Analysis. The pure coverage data comes from Xdebug PHPUnit2 "just" displays it nicely based on that. A quick look into the code revealed that it was easy to just use the CodeCoverage classes and so I integrated it in our testing framework.

He gives his example of how the code coverage looks, and gives the eight lines of code that it took to implement it - nice and simple...

On Christian Stocker's blog today, there's his experience with testing his code coverage visually with the help of the SimpleTest framework.

For our CMS, we use SimpleTest as testing framework. We used it in other projects, and as you should never change a running team, we sticked to that for Flux CMS as well.

But one thing I saw over at PHPUnit2 and badly wanted to have, was the Code-Coverage Analysis. The pure coverage data comes from Xdebug PHPUnit2 "just" displays it nicely based on that. A quick look into the code revealed that it was easy to just use the CodeCoverage classes and so I integrated it in our testing framework.

He gives his example of how the code coverage looks, and gives the eight lines of code that it took to implement it - nice and simple...