Following the work on the Main class comes the Controller class. There are some possible issues I want to test and will throw any generated exception to be politely handled by the Main class. The rule of not breaking a theme template with any error still stands.
Battle hardening the Controller class
While setting-up the tests for the Controller class, via the extending FirstController class, I got rid of some not useful arguments, namely all, in its __construct method leveraging the information I can gather, at run time, from the get_called_class functions. PHP manual states that it
Gets the name of the class the static method is called in.
But will actually work in the __construct method as well. Which is in fact usable before any object instance is created and hence, my guess, somewhat static in nature.
The old version of Controller::__construct did take 3 parameters, each one a potential problem
public function __construct( $className, $namespaceName, $rootFolderPath );
and working some magic at runtime has changed into
public function __construct();
I’ve set-up some tests for the Controller class and since so many revolve aroun the filesystem I have set-up some possible scenarios to simulate possible failures.
/noViewsFolder
| /controllers
| | NoViewFolderController.php // defines the \TAD\Test\controllers\NoViewFolderController class
/testControllers
| | /controllers
| | | NoProperlyNamedViewController.php // defines the \TAD\Test\controllers\NoProperlyNamedViewController class
| | | NoProperlyNamespacedViewController.php // defines the \TAD\Test\controllers\NoProperlyNamespacedViewController class
| | /views
| | | NoProperlyNamespacedViewView.php // defines the NoProperlyNamespacedViewView class
and moved to testing the possible errors in code writing some tests before
public function testConstructWillThrowIfNotDefinedInTheControllersNamespace()
{
$this->setExpectedException('RuntimeException', null, 1);
new NoNamespaceController();
}
public function testConstructWillThrowIfNoViewFolderIsFound()
{
$this->setExpectedException('RuntimeException', null, 2);
new NoViewFolderController();
}
public function testConstructWillThrowIfNoProperlyNamedViewIsFound()
{
$this->setExpectedException('RuntimeException', null, 3);
new NoProperlyNamedViewController();
}
public function testConstructWillThrowIfNoViewClassIsFound()
{
$this->setExpectedException('RuntimeException', null, 4);
new NoProperlyNamespacedViewController();
}
The power of the numbers
In the tests I wrote yesterday for the Main class I had to test for output, due to the Main classy politeness, while I’m able, while testing the Controller class and the View class, to test for the way more reliable and future proof error numbers. Proper error throwing, catching and handling is something I’ve personally began to leverage adopting TDD techniques and the error number was a possibility I had often overlooked.
View gets little testing but its existence is an open question
The view class get very little testing at the moment and it’s way more interesting when seen with the eyes of utility.
Why, having chosen to skip a proper Model class in favor of WordPress already built-in functions, implementing a View class? The same result the View class actually returns could be easily obtained with a simple include call.
The reason is that what is now a redundant call allows me to keep the framework ready to accept more elegant templating solutions. I do not use mustache but might one day and having to re-implement just one class, the View extending one, makes me feel comfortable.
Integration
Three parent and three child classes means problems and, to prevent them, integration testing. Right now the framework has just one integration test
public function testThatCallingMainShowProperlyReturnsString()
{
$this->expectOutputString('First');
TestMain::show('First');
}
and it sums up the original framework objective for this week. Working on the code some more until unit and integration testing are both all green closes this week job with a first version of the framework.