conormulligan.com / blog

CodeUtopia has some thoughts on Unit Testing Zend Framework applications.

There are some good points made, particularly on the difficulty of realistically testing Controller classes:

Controller testing can be the most difficult part, and this is where you may need to perform some refactoring if your design is not suitable for testing. For example, you may have a lot of logic in your controllers, which might be better off in your models or library code. Testing the whole idea of getting out the correct output or redirects may be difficult.

Zend probably should have had a Unit Testing strategy when developing the Framework initially, but, as always, the community fills in the holes. This also highlights another problem developing PHP applications: there is no standard build process, in which scripts can be unit tested, compiled, optimized, packaged, etc. There are solutions available (Phing is popular, it’s even possible to use Ant) but this is an area where Zend could show real leadership and come up with their own industry-standard, solution (maybe even as part of the Zend Framework, or Zend Studio). I’m not holding my breath, but you never know.

The surprising success of Rails has given rise to a huge number of PHP Frameworks that have recently seen a surge in popularity.

One of the much-lauded features in Ruby, and it’s PHP clones, is the adoption of an MVC Architectural pattern, which, simply put, seeks to separate presentation from logic from data.

Sounds great doesn’t it? The only problem is, using a PHP framework incurs a huge overhead for your application. Of course, all the frameworks in question offer much more than an easy way so structure your application, but if this is all you want you could be left with a huge library of classes that you will never use; hardly an ideal situation.

This is a dilemma in which I found myself recently. I was developing an application for a group of musicians around my area. I needed it to be speedy and reliable, so I was reluctant to use third-party code; no matter how acclaimed. But I also wanted to use MVC patterns, along with clean urls. As I was adamant about knowing exactly what was going on in my app, and am familiar with how most frameworks implement MVC, i decided to code a simple MVC system that I could build upon later.

Here’s the basics of how it works:

• .htaccess file: A rewrite rule is created to route all request (bar resource requests like .css files, .js files, images) to index.php, which handles all requests for the application; this is known as the bootstrapper.
• Bootstapper: The bootstrapper (index.php), is where all requests from the client are routed. This script simply establishes environmental variables, and runs the FrontController.
• FrontController: The FrontController is responsible for parsing the URI and forwarding requests to controllers and actions. The first piece of the URI (http://example.com/first) is mapped to a controller, the second (http://example.com/first/second) to an action, and all other elements are passed as parameters (http://example.com/first/second/parameter1/parameter2/parameter3). Once the FrontController has figured out what the URI should be pointing to, it runs the required controller and action. Note: if an action is not called, an action called Default, which is in every controller, is called.
• Controllers and Actions: The controller, which is always in the format ‘Controllername’Controller.php, is a class that is instantiated by the FrontController when called by the browser. Actions are functions contained within this class. If a user visits the url http://example.com/news, the controller NewsController.php is called, and the Default action is run. If a user visits http://example.com/page/about, the controller PageController.php is called, and the function About is run. If the page http://example.com/user/view/conor is requested, the Controller UserController.php is instantiated, the function View is called, and ‘conor’ is passed as a variable.
• The Model: The model always refers to the data and the code that manipulates it. I implemented a simple wrapper class for mySQL and that was it.
• The View: The view is the presentation: the html, css, images, etc. Not wanting to completely reinvent the wheel, I just created another wrapper class that inherits Smarty. Although my aim with this application was efficiency, I didn’t mind using Smarty given its fantastic feature set like compiling and caching. I was already well-versed in its unusual syntax so there was no learning curve involved.

And thats it. This is a basic outline of how my system works; it is a near carbon-copy of similar systems like Ruby and the Zend Framework. I’m planning on writing up a simple tutorial for this; mainly so I have a reference to go back to in the likely event that I forget how I did it. In the meantime, you can see this in action here (Note: this site is nowhere near complete, so ignore everything except how the URLs work…).