MAX 2008 will be upon us soon and this year it coincides with our regular 3rd Wednesday for BACFUG. Accordingly, we have a special meeting with two presentations by speakers who are in town for MAX!
Bill Shelton and Marc Esher - creators of the awesome MXUnit testing framework - will be presenting "Unit Testing with MXUnit". Unit testing talks have proved very popular at BACFUG in the past and MXUnit has really raised the bar in terms of features and tools so it will be great to have the framework's creators speaking at MAX.
Our second presentation will be related to Model-Glue 3 "Gesture" and will again be the framework's creator, the amazing Joe Rinehart. Joe has hinted that he will be tailoring the talk toward integration with powerful Java technologies, along the lines of what we have achieved at Broadchoice.
BACFUG is free and open to everyone - both regular locals (who may or may not be attending MAX) and all those CFers who are in town for MAX! However, we need you to RSVP on the BACFUG website so that we can figure out numbers and book a large enough room!
- Monday
- Opening General Session
- Adobe Roadmap: Enterprise
- Flex Architecture Face-Off - panel
- Real-Time Collaboration Apps with Flex and Cocomo - Nigel Pegg
- Tuesday
- Mixing Open Source and Commercial Software
- General Session
- Adobe@Adobe: IT Innovation
- Developing Rich Applications with jQuery and Adobe AIR - John Resig
- The REST of SOA
- Wednesday
- Advanced Patterns for ColdFusion Test Automation - Bill Shelton / Marc Esher (MXUnit)
- Building Real-Time and Collaborative Applications with Flex and BlazeDS
- Event-Driven Programming in ColdFusion - an updated version of my session from Scotch on the Rocks and CFUNITED
- Cocomo Deep Dive: Building Social RIAs with Flex + Adobe Hosted Services - Nigel Pegg
- Developing Enterprise ColdFusion Applications - Joe Rinehart
Also a reminder that BACFUG meets on the Wednesday evening immediately after MAX ends and I am pleased to announce that we are having a double session with some MAX speakers:
- Bill Shelton and Marc Esher will present on Unit Testing in ColdFusion with MXUnit
- Joe Rinehart will present on Model-Glue 3: Gesture
I'm a big fan of unit testing but for a variety of reasons, we haven't quite established TDD as a day-to-day part of our operations at Broadchoice (something I want to change and as we bring on new team members this summer, we will instigate this as "Standard Operating Procedure").
However, today I wrote my unit tests first because I wasn't quite sure of my TQL syntax and figured that writing the tests first would help me navigate to the correct code.
It worked! Not only did I (re-)learn the lesson that TQL does not allow select class.* ... (Why Mark? It allows select * .... Can't it figure out all properties of a specified class? I know, enter it as an enhancement in the Transfer bug tracker!), but I also uncovered a bug in my transfer.xml file and a few other typos in pieces I'd mistakenly written before I started on these two decorators and their tests.
So, there you have it: write unit tests! Write them before you write your code! It helps you avoid committing code that won't run and that means less pain for your team members.
As folks know, I've been a big fan of unit testing for quite a while and used to advocate Paul Kenney's cfcUnit at every opportunity. Unfortunately, Paul hasn't been working on cfcUnit much for the last few years and MXUnit has grown up to take the crown of the most comprehensive, most robust, most feature-rich testing framework for ColdFusion.
If you're still not doing unit testing, you need to check out the MXUnit website and try to get to at least one of the presentations that the MXUnit team are giving. They're on the Online ColdFusion Meetup on Thursday July 17th (database patterns for unit testing - Bill Shelton) and if you're at MAX 2008, you can catch Marc Esher talk about advanced patterns for ColdFusion test automation which should be excellent (Wednesday, November 19th @ 9:30am).
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.
