I've been using Brian Kotek's ColdMock for a while and I really like how easy it makes it to test CFCs that depend on several other CFCs - because you can create "mock" versions of those CFCs on the fly that return specific values. Mock objects are a good way to provide a consistent environment for your CFCs under test, as well as a way to let your CFCs be tested without them affected the "real" environment (because you can create a "mock" environment which can even include things such as data access objects to fake the whole database layer).
As I blogged recently, I've switched from cfcUnit to MXUnit and the mailing list is pretty active. Mike Steele posted that he had ported EasyMock to CFML. My first reaction was "Have you looked at Brian Kotek's ColdMock project?" and Mike explained that EasyMock isn't just about creating simple mock objects but about verifying behavior in those mock objects.
Intrigued, I read about EasyMock, a Java project that targets JUnit, and realized the power of being able to create mock objects that expect to be called in certain ways and can, as part of your unit test, actually verify the calls made on them!
I asked Mike to send me a build and I played with it and liked it a lot, pretty much instantly. I sent him some feedback and very soon I got an updated build that incorporated much of my feedback - and a note saying he was already going in that direction. Nice to find a project where I'm on the same page as the author!
You can download the latest build from the CFEasyMock project page on RIAForge. It's a very simple but very powerful concept that should really help you with your unit testing!
Since unit testing has become an increasingly important part of any project that I work on, I've had to review what else is available. Right now, the best of breed for ColdFusion seems to be MXUnit.
You can view the recording and it's already posted on Charlie Arehart's UGTV site. We had a few technical problems: Connect crashed for me (which didn't seem to affect the recording) then Connect crashed for Paul two or three times, causing breaks in his presentation as he had to log back in and restart his microphone and screen-sharing. Thank you for your patience! The problem seems to be the Connect Add-In on Intel Macs - I think it runs under Rosetta and it's pretty flaky.
First, if you haven't already done so, install cfcUnit.
Second, if you haven't already done so, you need to install the new CFUnit plugin. In Eclipse, Help > Software Updates > Find and Install... and search for new features on the CFEclipse update site. You should see a CFUnit 1.0.4 plugin. Install that and restart your workspace.
Third, download my facade CFC and put it somewhere that is web accessible (I put mine in my webroot).
Then configure the CFUnit plugin to use that location, under Window > Preferences > CFEclipse > CFUnit. Specify the URL to the directory containing the CFEclipseFacade.cfc you just downloaded.
Finally, open the CFUnit view (Window > Show View > Other and select it from the CFML section).
Now you can enter a CFC path - or search for CFCs - and run them directly in Eclipse.
First off, the CFUnit code is Windows-centric, assuming expanded file paths contain \ instead of testing for both \ and /. That was an easy fix but I really wish ColdFusion developers would think about this issue when they're providing code for others to use!
Second, the Eclipse facade for CFUnit has pretty much zero documentation and next to no comments so it took me a while to figure out that it assumes the facade is actually a test listener. Once I'd figured that out, it was relatively straightforward to convert it over to work with cfcUnit. Up to a point.
Update: I have a fully operational facade CFC for cfcUnit that works smoothly with the CFUnit plugin. I've sent a copy to Robert Blackburn to review and also to Paul Kenney. Once I have their feedback, I'll post the CFC here for folks to download (in a post containing instructions on how to set it up).
http://www.pjk.us/paul/rss.cfm?mode=full
These are the docs included in the latest cfcUnit 1.2 download but of course a lot of people want to read them before downloading the framework!
The docs cover how to get started, how to write tests and test suites as well as how to integrate cfcUnit with ant and Eclipse. They also show how you can run tests written for CFUnit so if you've been using that framework, you can easily migrate to cfcUnit!
Expect more blog posts about this in due course (although this blog post about automation may help you get started).
It also includes the ability to provide arguments to test suite code at runtime - I'll blog more on this in due course because this is a feature that I originally hacked into the framework and then Paul had to completely rewrite so that it matched the architecture. Sorry about that Paul!
- add the new table to the .sql scripts
- run the scripts to rebuild the test database
- add a method to the model CFC that uses Transfer to retrieve the data
- add a method to the web service facade that calls the method in the model CFC
- add scaffolding to the admin console to manage the new table
- tidy up the scaffolding (see my recent notes from the trenches on how we use scaffolds for prototyping)
Can anyone see what key steps are missing here?
Yup, the very first few steps. The ones that cover writing the unit tests. So as I said, I took a shortcut. I didn't write a unit test.
Guess what? My colleague found not one but two very simple, silly bugs in my code! Both would have been easily found by the most elementary unit tests that I could have written.
After fixing both bugs (separately: the fix the first one uncovered the second one!), I got around to writing the unit test I should have written in the first place and thus saved not only my time but, more importantly, my colleague's time.
So, don't take shortcuts - write your unit tests first!
I've talked before about the structure of our service-based system: we use ColdSpring to manage all of the model components; we have simple web service / Flash Remoting facades in front of that model; we share that configuration with our Model-Glue applications using the parent bean factory feature of ColdSpring. I've been focusing on the Model-Glue side of the things this week, so I thought I'd blog about how that's working out for us.
Sean, any chance you may release the unit tests for this? I'd love to see some "Real World" test cases for a component like this.Yup! I've updated the ZIP file (12Kb) to include the cfcUnit test case and helper CFC.
Since a couple of folks have heard me talk about this and asked me to blog the 'how to' I figured that even in advance of Paul officially releasing this, I'd go ahead and explain what you can do with it and how easy it is to set it all up.
The REST adapter exposes a single method. You POST an XML packet to it with a 'payload' argument whose root element names a component and has an attribute that specifies the method to call. Child XML elements specify the arguments to pass to the method. The REST adapter understands essentially the (Cold)Spring DTD XML definitions for values, lists, maps and beans and handles inbound arguments in that form and then encodes results in that form.
Because this is such a critical generic component, I've been writing test cases extensively - in advance of writing the actual code - so that I have a good degree of confidence in the resulting code.
It's been an interesting exercise. Write a test case. Run the test. It fails. Write the code in the REST adapter. Run the test. It passes. Well, in theory it does. Rinse and repeat. The nice thing about this is that you're thinking about the API and the error messages, not the implementation. You define the expected behavior, the concrete requirements... then you think about how to make it behave like that.
Try it, you might like it.
Download cfcUnit today!
p.s. I'll look into whether or not I can open source the REST adapter - I suspect other people may find it useful.
