I had trouble getting PHPUnit to load under Windows, so I’ve built a test suite of my own. It isn’t as powerful as PHPUnit (nor does it preclude using PHPUnit at some point in the future), but it is able to check the public inputs and outputs of the classes it tests.
I’ll share it with whoever’s interested - it uses closures to hold the tests and namespaces to segregate test environment from framework environment. The backbone is a single class - UnitTest, and all the tests build from it. They also follow their normal inheritance pattern after the initial test. For example, TierArray extends from ReadOnlyArray. The test of TierArray, also named TierArray (but in namespace GazelleTest) extends from ReadOnlyArray (again the copy in namespace GazelleTest) which then extends from UnitTest.
The test suite has a copy of the autoloader used by the framework that is simplified to make its debugging easier (cause the last thing I need is a test component acting buggy).
I’m wondering on where mock classes should go. Following the example above, TierArray is abstract. Hence it can’t be directly tested unless a dirt simple concrete class is made - a mock class. Currently I have mocks off in their own directory where the autoloader can find and fetch them. I’m considering placing them in the same file with the main test, but if I do that I’ll have to use the braced namespace convention because the file will have code from two namespaces.
I’m a little torn as to which way to go. The mocks are part of the test, but not a part if that makes sense.