In my last article about unit testing, I mentioned one way to do ad-hoc multiple joins in CakePHP rather succinctly. Here’s a recap:

This is, of course, rather unintuitive. A hasOne relationship when in fact I’m trying to look for someone hasAndBelongsToMany? I thought more about it.

There is a Bakery article that talked about doing ad-hoc joins. It looks more technically correct but just too freaking much verbose for my liking:

Actually, a simple refactoring can make it (almost) syntactically sweet and technically more correct:

Today I’ve finally formalized a streamlined procedure to do unit testing properly in CakePHP — without all the pain. Needless to say, The Cookbook’s chapter on this issue cover the basic grounds but is inconsistent and lack a real life feeling to it.

The Cookbook’s coverage is really basic and doesn’t hold up to more real life complicated cases. Cake seems to be particularly picky about its automagical (too clever for me to figure out for a long time) configurations and bark errors at me very often. That led to reluctance to write tests and sometimes giving it up all together :p

The steps I’ve written here should lay down a very solid framework to make you bullet proof for all your future testing needs.

(Of course, this might be coming a bit late since most people would be better off looking at Cake’s successor Lithium, anyway here we goes.)

Can’t gather up much time to make a polished article but I believe this point-form brain dump is much more effective than most documentation out there.

Testing models

First, some notes

• Testing models is the most important thing. Of course, a proper MVC application should have fat models and thin controllers.

• For the most part, you really should use fixtures even if you do not use fixtures to load data. If you just use the database live, chances are Cake might mess up your data and errors might pop up, just go ahead and use fixtures. Yes, you don’t need to load data with your fixtures if you don’t want, but you need to turn this feature on. Yes, this was the thing that confused me a lot.

• CakePHP uses SimpleTest, you would think that you’d put your setup and teardown code in setUp() and tearDown() just like everybody else? Wrong. Cake has already invaded those spaces. You’ll need to use startTest() and endTest(). This was documented in the Cookbook but this took me quite some time to figure out since I took it for granted and didn’t RTFM.

• I may cover controller testing later but IMO controller testing in Cake is mostly broken and is quite straight forward to figure out.

Testing models — the tutorial

First we’ll set up the database, install SimpleTest etc. If you don’t know how to do this step you should read the Real Manual first.

Set up our testing application database in (My)SQL.

Bake our stuffs. Bake has come a long way since the earlier versions and the bake in Cake 1.3 is genuinely useful:

Now go create some test data:

Now open /app/models/post.php and /app/models/tag.php. Both look OK! And Cake has gone ahead and created the test cases for us at /app/tests/cases/model. Let’s try to run it

This is how broken it is! Now let’s fix it. The thing is that we haven’t baked the fixture for the join table class PostsTag. Of course, we don’t want to have to create controller, models, views just for a simple join class. Luckily we can amend it by creating all missing fixtures:

This will create all the missing fixtures. The -records -count 999 part tells Cake to pull real data from our database as fixture. The -count part is needed because it defaults to 10. Might as well enter some very large number but YMMV. This will also update our existing fixtures for Post and Tag so that the new fixture data we’ve added to the database will be reflected in the fixtures. Let’s try to run the tests again:

Finally, we’ve got the testing architecture down. To honor TDD, let’s create (edit) our test file before we do some development. Now go to /app/tests/cases/models/post.test.php, you’ll see this line:

This is unfortunate, because it means every time you add a new association to your model, you’ll have to manually edit this $fixtures array. Too bad there isn’t an automated way to do this. (Running bake test will overwrite your whole file. You’ve been warned!)

Anyway, let’s just write some tests for kicks in /app/tests/cases/model/post.test.php:

Run it, all is good:

To honor TDD, we’ll write our test first before we do any implementation. Let’s add our test function. We’re going to write a model function that will find all posts for a given tag:

Run the test and watch it fail:

Do our implementation in /app/models/post.php

The above trick was used to force CakePHP to do left joins for us. There is an article that talks about this technique on the nuts and bolts of cakephp blog.

Well, let’s add one more test. We want to make a function to get us the content of a post:

Run it, watch it fail. And then we add our implementation:

Great, now run it and expect it to pass….

Wtf!? It failed? Yeah, we forgot to update our fixtures. That’s it. Every time we update our database, we need to update the fixture. Fortunately, this is one area from Cake that is really painless:

The fixture updating part was a little redundant, but it’s better than manually updating the fixture from SQL and also from *_fixture.php. I suggest you can store all your test fixtures data into an SQL file and make some bash script or ruby script to deconstruct the database and load the test SQL file for each test run. You can play around with different connection settings if you don’t want to sabotage your main table for every test run. You can package this loading of SQL file and the fixture baking into one script file so that it can be done in one click. (left as an exercise to reader)

That’s it! In retrospect, it isn’t rocket science, it’s just that I haven’t found any good piece of comprehensive tutorial that hand holds me from start to finish. I’ve been putting off a lot of unit test writing because I’ve always had Cake barking errors at me left and right. Now there’s no excuse

Super Awesome Advanced CakePHP Tips is free e-book about the CakePHP Framework. It covers topics that are generally missed in the beginner books that are on the market.

The CakePHP framework hasn’t been known for good documentation since its debut almost a couple of years ago. Now that the official manual > Super Awesome Advanced CakePHP Tips is free e-book about the CakePHP Framework. It covers topics that are generally missed in the beginner books that are on the market.

The CakePHP framework hasn’t been known for good documentation since its debut almost a couple of years ago. Now that the official manual The Cookbook has reached some maturity that this framework is actually possible for more mortals, there still seems to be a lack of materials bridging the masters and the newbies.

Super Awesome Advanced CakePHP Tips by Matt Curry is a good bridge for this gap. It covers topics beyond the basics but that are actually lifesavers when it comes to more complicated CakePHP apps, such as caching, performance, unit testing, configuration/deployment and stuffs.

Reading through the short book gives me a feeling that Matt really knows a lot about this framework. I don’t know why this book isn’t more popular than it currently is (maybe it’s just me, lol).