A Path Less Taken

I was recently working on a generic container class in PHP that implemented allowed, required and group behaviors related to assigned properties. While coding the class I built a test class using PHPUnit that had 7 tests and 33 assertions. After using the class on a limited basis I determined that the internal implementation left something to be desired. Unswayed I dug in and re-implemented the bulk of the internal methods without changing much of the interface of the class. I ran the unit test again and found that only 8 of the assertions related to the modified behavior needed to be updated. After I changed those assertions the class passed all the tests.

I know that many you are asking “what’s the big deal about that?” The big deal to me is that I’m often reluctant to write tests because I’m a hobbyist developer and I’m always anxious to get straight to the code. I guess you could say that this simple experience has changed my point of view. It is very powerful to be able to change a class as fundamentally as I did and still be able to validate that it behaves as desired with such ease. The benefit of all the upfront work in building unit tests was clear to see in this case.

If you have a similar experience or just a point of view one way or another on unit testing please post a comment below and share it with me.

Before you post a comment that says something like “there’s a Kohana 3 module that does that” let me just say I know and I’m grateful for it. Some of what I did was inspired by that module. The issue was when I tried getting the Kohana 3 unittest module to work to test my module it was giving me problems. I read the Kohana forum posts and the unittest documentation and could not find an answer. Finally I decided to start at the beginning and set up PHPUnit manually to work with Kohana 3 and my module to debug what I was doing wrong with unittest. In the process I discovered that getting PHPUnit to work with Kohana 3 wasn’t that hard after all. I thought I would share my solution in the event you are having similar issues.

Web development is a very common hobby. At least that’s what I keep telling myself. Whether it is or not, I’m a web developer. As such, I spend a fair amount of my spare time reading about web development, watching videos about web development and for sure doing web development. As I set out to install my development tools on my new computer I thought I would chronicle the process. If you’re interested in setting up your own web development platform using mostly open source tools then read on and check out my approach.

If you find that documenting your PHP projects is the least fun activity you can think of then you might want to give one of the automated code documenters a try. Below are two that may be worth a look. If you know of others then please post a comment and share.

• phpDocumentor – The complete documentation solution for PHP
• PHPDoctor – The PHP API Documentation Creator
• Doxygen – A documentation tool for PHP and other languages.

I recently upgraded my test web server to PHP 5.3.0 and ran into a couple of minor errors in the Kohana PHP Framework as a result. The first issue I found was several extensions that I use were now compiled into PHP itself. This means they were no longer in the ext directory. These included php_pdo, php_mcrypt and php_mhash. You can find the solution to that issue here. You need to make sure you comment out the lines in php.ini that attempt to include these extensions. The second issue I found was the register_globals directive in the php.ini file was depricated as of PHP 5.3. This means you should set the register_globals directive to Off in the php.ini file. This is what was tripping me up. I hope this is helpful to some of you.