A Quick Unit Test in Lithium 0.5
By David Golding
| 
Print This Post
Unit testing has always proven a chore in past projects. But a necessary one. The more specific the testing, the more effectively one isolates problems in the code. Well, and the more aesthetic, provided one knows how to use unit testing right. I have found Lithium’s built-in unit testing environment amazingly simple, and since a couple of folks have asked me recently about this feature, I thought I’d post a very quick unit test just to demonstrate how even a beginner can take up unit testing in Lithium in minutes. (This example already assumes you have Lithium 0.5 working in your localhost environment; if you don’t, take a look at Union of Rad’s installation tutorial or the project lead Garrett Woodworth’s screencast.)
Create the Test Class
To launch Lithium’s unit test dashboard, simply add test after your application’s root path. Assuming our new app is named “basic,” you’d type something like http://localhost/basic/test as your URL. By default, the dashboard only displays Lithium’s core tests. Let’s add one for our own app to evaluate a model.
Create a model test file in app/tests/cases/models and name it after the model class you intend to simulate. In my case, I’m testing a table holding data on composers for a sheet music application, so I’ll name my file ComposerTest.php. Now, place some standard code in this file so that the test classes will execute the unit tests appropriately:
1 2 3 4 5 6 7 8 9 10 11 | <?php namespace app\tests\cases\models; use \app\models\Composer; class ComposerTest extends \lithium\test\Unit { } ?> |
On line 3, we specify the namespace for this class, which corresponds to the path in the application where this test class appears. Lines 5 and 6 call two classes that will allow the ComposerTest class to connect to the database and/or run methods in the Composer model, which, of course, is my runtime model for all of my Composer methods in the live app. Line 8 names the class following a convention: we add “Test” to the end of the model name we’re testing and we extend from the core unit testing class available as lithium/test/Unit.php.
Go back to the unit test dashboard and your new test class should appear on the left under app > cases > models > ComposerTest. Click the link to run tests on ComposerTest, and the results should light up green with zero passes, fails, or exceptions.
Perform a Unit Test
A very basic unit test performs a query to see whether the model connects to the database and can fetch records. I’m going to write a test function that allows me to see whether my model can perform a basic find query. In the ComposerTest class, I’ve written a function called testWhetherDbQueryWorks() that asserts whether a result set is null or populated with table data. It looks like this:
1 2 3 4 | public function testWhetherDbQueryWorks() { $id = Composer::find('first')->id; $this->assertTrue(!empty($id), 'Query did not pull data'); } |
Simple enough. Lithium provides several other assertion methods, which are all described at the Unit class entry in the Lithium API.
Now, when I run the test in the dashboard, it ought to pass, provided I’ve set up my Composer class correctly.
Hope this helps for those beginners out there looking to try out Lithium. I’ll try adding more detailed information, or using screencasts, when I’ve got a little more time for documenting my experiences in Lithium.
Comments
Feb 15th, 2010, 12:52 pm
@gwoo: Thanks for the tips. Yes, definitely falling back on array structures. Once the model methods are finalized in Li3, I’ll take on those data objects with confidence ;)
gwoo
Feb 15th, 2010, 9:18 am
Nice article David! Actually you should not need the `use \lithium\data\Model` line. you could also do something like `$id = Composer::find(‘first’)->id` and then you would not need an exception, but I know you are used to those arrays ;)
Looking forward to seeing more articles.