I released Solar version 0.18.0 over the weekend. The biggest change is in the testing methodology (yes, again ;-).
After having used both, I can say that the procedural PHPT testing style is easier to approach for someone new to testing, and is great for smaller or standalone projects, but it doesn’t seem to “scale up” well for larger class structures. The object-oriented testing style used by PHPUnit and SimpleTest requires more inital setup work, but “scales up” much better in larger projects.
I used PHPUnit while working at Zend, but frankly it seemed kind of magical to me; I just didn’t get the way it worked internally, especially setting up test suites. PHPUnit is a robust and highly configurable piece of software, but it does seem a bit impenetrable. This may be due to the fact that PHPUnit is ideologically derived from similar Java projects, and I am just not a Java kind of guy.
So in a spirit of meet-in-the-middle, I coded up a pair of Solar-based unit-test classes to take over from Solar_Test_Assert and .phpt, then converted a couple of existing .phpt tests to the new technique. It worked like a champ. After adding a Solar_Test_Suite class to scan a base directory for test cases and generate TAP-compliant output, I converted all the remaining .phpt tests to the new object-oriented testing style. The new test suites run much faster, and it’s easier to extend an abstract test-class than it is to copy and modify a bunch of .phpt files.
You can see some code examples here:
- The abstract Solar_Test unit test class
- A concrete test for Solar_Uri
- The Solar_Test_Suite class
- The command-line test-runner
The test-runner is very easy to use. If you want to run all tests, just issue “php run.php” from that directory and it will recursively run everything in the Test/* directory. If you want to run a sub-series of tests, pass a class name as the only parameter; e.g., to run the Solar_Uri tests, issue “php run.php Solar_Uri”.
Test-runner output is TAP-compliant (which should make Mike Lively happy ;-). Among other things, this means it should be easy (in theory) to hook in to apache-test. TAP output looks something like the following:
bash-2.05$ php run.php Solar_Uri 1..21 ok 1 - Test_Solar_Uri::test__construct ok 2 - Test_Solar_Uri::test_config ok 3 - Test_Solar_Uri::testSet ok 4 - Test_Solar_Uri::testFetch ok 5 - Test_Solar_Uri::testQuick ok 6 - Test_Solar_Uri::testSetQuery ok 7 - Test_Solar_Uri::testSetPath ok 8 - Test_Solar_Uri_Action::testFetch ok 9 - Test_Solar_Uri_Action::testQuick ok 10 - Test_Solar_Uri_Action::test__construct ok 11 - Test_Solar_Uri_Action::test_config ok 12 - Test_Solar_Uri_Action::testSet ok 13 - Test_Solar_Uri_Action::testSetQuery ok 14 - Test_Solar_Uri_Action::testSetPath ok 15 - Test_Solar_Uri_Public::testFetch ok 16 - Test_Solar_Uri_Public::testQuick ok 17 - Test_Solar_Uri_Public::test__construct ok 18 - Test_Solar_Uri_Public::test_config ok 19 - Test_Solar_Uri_Public::testSet ok 20 - Test_Solar_Uri_Public::testSetQuery ok 21 - Test_Solar_Uri_Public::testSetPath 21/21 tests, 0 seconds 0 fail, 0 todo, 0 skip, 21 pass bash-2.05$
There’s also a test-maker script that generates a skeleton test class, with a test method for each public method in the target class. Just issue “php make.php My_Class_Name”.
And of course, if you write your libraries to Solar standards (which are essentially PEAR standards with a couple of additional points) then you too can use the Solar_Test tools to make your testing life much easier.
Update (11 July 2006): Updated links to point to new SVN directories. Thanks, Clay Loveless.