What it does
In PHPUnit’s preferred testing architecture, every package and subpackage has it’s own testing suite in a AllTests.php script. Those testing suites can be hierarchically composed to build one big testing suite for your project.
ZFTestManager adapts to this architecture and scans your tests directory for AllTests.php to create a list of testing suites. It allows you to:
- list all suites
- run suites, filtered by regular expressions
- create new suites (by creating a AllTests.php skeleton)
Furthermore, it offers a configuration file with a section for each test. There, I can define DB credentials, hosts, ports, paths and so on. Quite handy to have all config settings of my tests in one single file.
What it does not
Unfortunately, it’s not the solution we’ve been looking for. Since ZFTestManager takes over the dirty job of finding and running my tests, why do we still need those tedious AllTests.php files and all the deadweight code in our tests? In my opinion, using a managing script makes the possibility of running tests directly from shell obsolete. And why does ZFTestManager create skeletons for AllTests.php instead of creating the test skeletons directly?
I guess, it’s all a matter of taste. I prefer my test files to contain just the test class, nothing else. And obviously, I don’t take to kindly to AllTest.php scripts. That’s why we’ve created our own test manager (reusing ZFTestManager is near impossible, unfortunately) that searches for tests instead of AllTests and that is able to create test skeletons, instead of suites.
This way, we removed the hierarchy from unit testing for more simplicity. Since all our classes are properly named (
Project_Package_Subpackage_Class), we can still test by packages, just by using the right regular expression, like
"Project_Package". We now have our very own opinionated test manager, including convention over configuration, baby!