I would like to thank everyone that offered suggestions for what they would like to see in the next version of cfcUnit. Many of these are great ideas, and some will certainly be added to the core framework. They have given me something to focus on and a bit more future food for thought.

Something else that is made much clearer is that more documentation, tutorials and examples are needed to get people started more quickly. I will be addressing that.

I would also like to remind folks that there is a cfcUnit mailing list (link below). If you have any ideas or questions about how things work, it is a good way of getting some help.

I have spent these last few months working on the next release of cfcUnit 1.2, so it has been on my mind quite a bit. While I add important functionality to the framework like a remote service for Flash Remoting and a rather robust Ant task and fix some long-standing issues, I can't help wonder if there is something else I need to add. So I pose this question to you: What do you want to see in the next release of cfcUnit?

If you already using cfcUnit for your unit testing needs, what would could be done to make your experience that much better? If you are not writing unit tests right now, what would it take to change your mind?

There are a number of people writing of the improvements in the latest version of cfcUnit, and I have not been one of them. So, you might be wondering why. Well, this last month since CFUnited, I have been busy making cfcUnit 1.1 ready for full release. That means fixing some bugs, adding some new assertions, and most importantly making sure that there is some better documentation available. On top of all that, though, I have been very busy making sure that you can run cfcUnit from everyone's favorite build tool, Ant.

Apparently, the absence of a cfcUnit Ant task and the existence of one for CFUnit has been a critical distinction between the two CF testing frameworks, giving people a reason not to use cfcUnit. Well, at CFUnited John Paul Ashenfelter took the initial stab at this elusive feature to show that it could be done without too much effort using the existing test runner that produces its results in WDDX.

There were a couple of problems with the first implementation, first among them that JDOM was used to process the XML document. This meant that when using the cfcUnit Ant task, you had to first download and install the JDOM libaray (and any of its subsequent dependencies) somewhere in the Ant classpath. A number of people discovered just how difficult (and not to say tedious) this process was for them just to get going.

Another problem was that the data format produced by the test runner was WDDX, a format that isn't very friendly to someone trying to read using XPath expressions since it really conveys no meaning at all to anything besides another WDDX parser.

So, what did I do about this?

Well, the first thing I did was come up with a new XML grammar that better describes the test results in a much more concise way. Once the format was in nailed down, I wrote a test runner to produce that XML. Once that was done, I needed to fix the problem posed by JDOM and its numerous dependencies.

One thing that is nice about Ant is that it is configured using XML. In fact, it uses Xerces and Xalan to process build configuration files, and I figured the cfcUnit task could take advantage of the fact that by running inside Ant it already has access to these libraries. So, after a bit of work, the cfcUnit Ant task is now a lot easier to install without any external libraries.

Now, some people might be wondering why I have gone to all this trouble of producing XML in the test runner and parsing it in the Ant task. Why not just format the text in ColdFusion and just display it in the console? Well, there is a good reason for this, and its pretty simple really. By sending raw data to the client, I can give the cfcUnit task a lot of options in how it handles errors and failures in both the individual tests and in the test runner itself. It can be configured to halt a build when something fails or to keep going, or show a full formatted stacktrace generated by an error inside a test.

Anyhow, after working with Ant for a little bit and seeing how Eclipse can automatically run cfcUnit whenever a file is changed, I can see why some people have gotten all bent out of shape because cfcUnit did not have an Ant task, but I'm sure that will all change soon.

Anyhow, here are some of the things others have been saying about cfcUnit lately:

• Unit Testing Love Affair
• CFCUnit Assertions
• Automated Testing with cfcUnit
• Thank you Paul and John Paul!

There has been a lot more attention paid to testing CFCs this year at CFUnited, and cfcUnit is right there at the front when discussing unit testing one's CFML. Perhaps the biggest proponent of unit testing has been John Paul Ashenfelter and his talks on Agile Development and Testing ColdFusion. Additionally, I have seen demos of unit testing by Chris Scott when showing off different functionality of the ColdSpring framework.

A side effect of this attention has been that there will soon be a new Ant task written by John Paul that will allow cfcUnit to be run as a part of an automated build, but it could also be run from within Eclipse just as other unit testing frameworks do now.