I published a change to Squidhead earlier today that included an option for Squidhead to write its own unit tests today. These unit tests are compatible with and require CFUnit. Here’s a little bit about the reasons behind this.
I originally started fooling around with unit testing because after drinking Pragmatic Programmer Kool-Aid, and attending cf.Objective, it was the next thing on my list. I figured I would be pulling them into Squidhead, as it’s pretty easy to tell if Squidhead worked (the application is either written or not,) but it’s hard to tell if the created application is working. So I started to write unit tests for my DAO Objects figuring it would be an easy place to start. Once I got one working, I realized it was relatively rule based and could stand to be generated itself.
What it does is:
- Create a mock struct of the record.
- Create a mock struct of the record slightly different from the first.
- Create a record from the mock record.
- Read it back and compares it to the source.
- Update it according to the different mock record.
- Read it back and compares it to the source.
- Delete the record
- Read again to make sure the item is gone.
All that is wrapped in a <cftransaction> making sure the thing never happened. Additionally it reads in and honors foreign key constraints. It’s got some weaknesses: it doesn’t like binaries or images; its smalldatetime check is only accurate to the hour; and there are probably more bugs lurking.
Now once I got them working, they were in, but what’s the point for users of the application? One should expect that the parts work.
So to make this worthwhile I added some logic that will run any test that is in the test directory structure. So if you’re using Squidhead and looking to dip your feet in the waters of CFunit or unit testing in general here’s your chance.
If you’re wondering why CFUnit, and not CFCUnit, it’s because as far as I can tell CFCUnit requires Mach II, and I figured one requirement was better than two.
So if anyone has any suggestion on how to test gateways or dao’s I’d be curious. Otherwise check it out.
tpryan.blog 
cfcUnit does NOT require Mach II!!
cfcUnit has ant integration, can be run by the CFUnit plugin for CFEclipse and the ASFusion folks created a Flex front end for it (which they could not do for CFUnit due to the poor architecture of the latter).
cfcUnit also has an HTML “runner” application. That happens to be a Mach II application but uses a built-in version of the framework so you don’t need to download or install anything other than Mach II.
Adobe use cfcUnit extensively as do several other companies I’ve been dealing with lately. Having Squidhead generate cfcUnit test stubs would be far more valuable.
LikeLike
Argh! Typo:
You don’t need to “download or install anything other than cfcUnit.” Sorry. See what happens when you get me frustrated?
LikeLike
Sorry Sean, I didn’t mean to make you angry. I was thrown off by the documentation on CFCUnit’s site, on page: http://www.cfcunit.org/cfcunit/docs.cfm that states: “Before you install cfcUnit, you must be running CFMX 6.1 and the Mach-II (1.0.9) application framework.”
That being said. I’ll take another look at CFCUnit. But I’m curious, not challenging, why CFCUnit? CFunit has Ant integration. CFUnit has an html runner and a front end. Is it the difference in architecture that you alluded to? Does CFCunit have better tests? (Which would definitely motivate me.)
LikeLike
Hi Terrence,
I noted a while back on my blog some of the differences I found between CFUnit and cfcUnit:
http://www.rbdev.net/devblog/index.php?entry=entry051116-030332
Since then I have also added a mock object CFC to the CFUnit framework – which I personally think is a very handy tool.
In the end, I think both frameworks are very good. And I think the important think is just that you unit test at all, which framework you unit test with is secondary.
LikeLike
Thanks Robert, that did shed some light on things.
LikeLike
I started to work on auto generated unit tests with Brian Rinaldi’s cfcGenerator a while ago. I only got around to generating tests for Beans and DAOs as I couldn’t figure out how to best populate the database to test gateways. One thing I’d be curious to know, do you test against a production database? What I ended up doing was having a blank scratch database, then I created and droped necessary tables in my setUp and tearDown methods. Looking back I don’t know if that was a good idea or not.
LikeLike
I’m only doing (and recommending) unit tests against development databases. I actually do all of the database stuff within an cftranaction that is rolled back. So the database is none the wiser.
LikeLike