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.

The system requirements for me were the following:

• LightTPD HTTP Server
• PHP 5.3.2
• Kohana 3.0.6
• PHPUnit 3.4

First I set up my Kohana 3 app normally which included the module that I wanted to test. I edited the default controller and created a class instance of an object from my module to verify there were no syntax errors. When that worked as expected I removed the new code from the default controller restoring it to it’s previous state.

Next I downloaded a copy of PHPUnit from here. I chose to manually install PHPUnit rather than use the PEAR installer so I could learn more about how it worked. I opened the .tgz and .tar files and copied everything inside the PHPUnit-3.4.9 folder into my php\pear folder. Then I moved the phpunit.php and phpunit.bat files into the top level folder of my Kohana 3 module (as in myapp/modules/mymodule). We have to edit both of these files.

With the files in place I opened phpunit.bat in my editor. There are only two lines that execute at the bottom of the file. I commented out the first line and changed the second on by replacing the @php_bin@ inside of each string with the following:

1. Replace the first @php_bin@ with the explicit path and file name of the command line PHP executable (in my case something like c:\php\php.exe).
2. Replace the second @php_bin@ with the path to the phpunit file (our phpunit.php file in the same directory as this file that we will rename next to just phpunit).

I then saved the changes and closed the file.

Next I renamed the phpunit.php file to just phpunit with no file extension. Then I edited the file and made the following changes:

1. Insert the following line below the Copyright notice (thanks to unittest’s author for this idea):

   1	define ('SUPRESS_REQUEST', 'SUPRESS_REQUEST') ;

2. Insert the following line after the if block that includes a call to set_include_path:

   1	set_include_path ('.;c:\php\pear;c:\lighttpd\htdocs\aa\modules\mymodule\tests') ;

   The first path statement is to the php\pear directory where PHPUnit is found and the second is to the tests folder (you need to create this folder) where the unit tests for my module will be created. I created mine in the root directory of my module.

After making those changes I saved and closed this file.

Next I edited the bootstrap.php file found at myapp\application\bootstrap.php. I modified the last statement as follows:

1
2
3
4
5
6
7
8
9
10
11

if (! defined ('SUPRESS_REQUEST'))
{
	/**
	 * Execute the main request. A source of the URI can be passed, eg: $_SERVER['PATH_INFO'].
	 * If no source is specified, the URI will be automatically detected.
	 */
	echo Request::instance()
		->execute()
		->send_headers()
		->response;
}

This is part of what I copied from unittest. It allows PHPUnit to bootstrap the Kohana framework using index.php which in turn calls bootstrap.php without actually taking the final step which is sending the response back to the browser with this statement. When I was finished with this I saved and closed the file. I also went back to the browser and confirmed that the site was still functioning normally.

All that was left was to write a unit test and try it out. I followed the guidelines found here for writing a unit test. Then I saved the test file, opened a command window, navigated to the root directory of my module and ran the following command:

phpunit --bootstrap=c:\lighttpd\htdocs\myapp\index.php MyTestFileName

PHPUnit ran, bootstrapped Kohana 3, executed my test and returned the result.

That was all there was to it. I’m not willing to suggest that I’ve solved all the issues. I did not deal with any database connections nor did I try to test the behavior of any response code, but I still think this was a pretty simple way to get PHPUnit unit tests enabled for a Kohana 3 module. If you wanted to do this for the application I think you just move the tests folder to under the application folder (myapp\application\tests) and update all the other steps to reflect that location. If you are also having problems getting your Kohana 3 and PHPUnit unit tests to work and want to learn more about PHPUnit then give this approach a try. If you have any questions leave a comment and I’ll be happy to help if I can.

The three most harmful addictions are heroin, carbohydrates, and a monthly salary

I’m willing to add video games to the list. None the less the last item caught my attention as intended. I want to say that I’ve heard it before, but seeing it in this context was still thought provoking.

520

		$this->dbh = @mysql_connect( $dbhost, $dbuser, $dbpassword, true );

For those of you not familiar with the @ symbol’s use in PHP let’s just say that in simple terms it prevents error messages from being displayed. I assume this is here to prevent UID and PWD from leaking out, but it also prevented me from knowing that the problem was with my MySQL connection until I traced this statement down. Annoying.

Armed with this knowledge I was able to do some more intelligent searching. First I looked up the mysql_connect function. Down in the comments there was a very helpful comment by Bruce Kirkpatrick that explained what was causing the issue. The new behavior of mysql_connect was relying on my hosts file to resolve localhost on Windows 7. This was based on the change not from Windows Vista to Windows 7, but on the change of PHP 5.2 to PHP 5.3.

So I opened my trusty text editor as administrator, navigated to where the hosts files should be and nothing was there. Even the etc directory was missing. I checked out the Wikipedia article on the Hosts (file) and discovered that users of Windows 64 bit OS’s (other than Windows 7) could not access the hosts file with a 32 bit editor. Since my editor is 32 bit, I could navigate as far as c:\windows\system32\drivers\ and then I could not see the hosts file. So what I did was type in etc\hosts in the file open dialog box and it opened as expected. I then uncommented the following line by removing the # symbol at the start of the line.

1

	127.0.0.1       localhost

I saved my changes and tested my blog site again using localhost and it worked perfectly. It worked so well that the post you are reading was the first that I penned on my blog’s new server. If you run into a similar problem I hope that this post can save you some time.