An Architect's View

I'm working on a specification suite with Pat Santora, who recently joined the Edmund Event-Driven Model project as a contributor (more on that shortly), and we're using cfSpec to define the expected behavior of Edmund.

[Read more →]

Ron just posted a new version of cfSpec to RIAForge that improves performance, adds a convenient way to run a directory full of specs and overhauls the "should" matchers to provide a much richer set of expectations. Check out Ron's blog post for more details of this new release.

I finally got around to adding the recording URL to Charlie Arehart's UGTV. It's a bit of a wild ride: it's two hours long with a 5-10 minute pizza break in the middle (sorry, Connect doesn't let you edit out the middle of a recording, only the start / end). If I'd known how limited the Connect editing was, I'd have made two separate recordings. Anyway, here is Unit Testing Improves Your Love Life - and - Groovin' To The Fusion: Marc Esher and Bill Shelton of MXUnit fame kick off the first hour and then Joe Rinehart of Model-Glue fame carries the second hour, explaining why a mixed language technology stack can make ColdFusion even more productive.

Ron has posted a great step-by-step tutorial for writing testable specs with cfSpec. Using an e-commerce shopping cart as an example, he builds up the spec, one expectation at a time, showing how cfSpec performs intuitive tests on the underlying objects, allowing you to write simple, expressive code, driven by your specification. cfSpec now includes "stub" objects (with true "mock" objects coming soon) so that you can specify the behavior of components independent from each other (so you don't have to write multiple objects just to get one object's expectations satisfied).

As "usual", I start the year with a round-up of the highlights of last year, based on things that I blogged. It's been a strange year for me. After (seven) years with Macromedia / Adobe and most of 2007 spent freelancing, I took a full-time job with a startup and hired some amazing CFers to be part of my team. I (finally) learned Flex (and AIR). I learned a new language (Groovy) and did a lot less CFML programming than I've done in years while at the same time joining first the Open BlueDragon Steering Committee and then the CFML Advisory Committee, as well as attending more ColdFusion-related conferences than usual (cf.Objective(), Scotch on the Rocks, CFUNITED, Wee Dram of Scotch, MAX).

[Read more →]

As folks know, I'm a big advocate of automated testing in general and unit testing in particular. I've gradually become a big fan of Test-Driven Development (TDD) where you write tests first and then write the code to satisfy the tests. I'm pleased to see unit testing well enough established in CFML development now that we have several unit testing frameworks (my current favorite being MXUnit, which I think has become the de facto standard choice for most CFers who are doing unit testing). Getting into TDD is not easy, however, and I think there are a couple of conceptual problems that take a while to get your head around. One is just a simple case of "Where do I start?". Given a blank piece of paper, how do you just start writing tests that are an accurate representation of what the yet-to-be-written system is supposed to do?

[Read more →]

Oh, sorry, that was the title of the BACFUG presentation by Bill Shelton and Marc Esher (of MXUnit fame)! Unit testing has defined my working day. I've been working on the licensing subsystem of the next build of the Broadchoice Workspace today and because we practice Test-Driven Development (thanx Brian!), that means writing unit tests "first" or at least alongside the production code. I started by writing the License bean and an accompanying LicenseTest. The bean has a handful of properties and two methods. The unit test has nine test methods. Fairly confident that the bean was correct, I moved on to the data layer. Apart from encryption, this mostly follows our well-tested generic Hibernate DAO. That meant only a couple of unit tests. Once those tests passed, I moved on to the service layer. Six unit tests for four service methods. At this point I'm ready to write the remote service facade (which implements user-level security) but I'm fairly confident our licensing subsystem will work as expected. 623 lines of code, just over half of which is unit tests (327 lines to 296 production code). I'll probably add some more data layer unit tests since I have a couple of "untested" methods (they're used in the service layer tests). Unit tests may seem dull and tedious but they really can make your life easier.

Important: you must RSVP via the BACFUG website. We have a hard limit of 47 attendees - if you do not RSVP, you may well be turned away. If we get close to 47 RSVPs, I will post again on my blog! 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!

I just made another pass over my MAX schedule to finalize my choices and thought I'd post my planned list of sessions so folks will know where to find me:

• 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

As I was updating my schedule, I noticed that several of the ColdFusion and Flex workshops are already sold out - good to see so much interest in those! I was originally going to Dave Watts' "High Performance ColdFusion" but decided to give up my seat when I saw it was sold out (hopefully someone else will get in now!). There's a lot of excellent ColdFusion sessions at MAX this year but my focus right now is on Flex, AIR and real-time collaboration so that has driven most of my session choices. 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

We hope to have a good turn out with MAX attendees taking advantage of this (free) user group meeting in the evening! Since the meeting is inside the Adobe building, you will need to RSVP for security purposes. See you there!

I'm working with Ray on some new features of the Broadchoice Web Platform and I'm building out some decorator methods to provide additional navigation across the object graph (essentially reverse navigation across many-to-many relationships). 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.