Come see us and many others at the WebManiacs Conference in Washington, DC, May 19-23 2008. http://www.webmaniacsconference.com/
The MXUnit team will be offering a 2 hour hands-on workshop: Implementing Test Driven Development with MXUnit.

Outline:
Test Driven Development (TDD) methods have gained recognition in industry because they allow developers to quickly identify defects in their code prior to integration. Discovering defects early contributes to higher quality software. It can also greatly improve a team's productivity and cohesion.

Workshop Goals: By the end of this workshop, participants will be able to (1) install MXUnit Framework and Eclipse Plugin, (2) write and run unit tests, (3) build test suites that test real world applications, and(4) understand the value proposition for unit testing and be able to communicate their findings to co-workers and peers.
Overview: This workshop will guide ColdFusion developers in the practice of TDD using MXUnit, an open source unit test framework and Eclipse Plugin, based on the popular JUnit unit test framework for Java.

Integration Practices and Automating Testing with Ant
a. Overview of Integration Techniques
b. Overview of Ant and basic Ant tasks
c. Description of the MXUnitAntTask
d. Writing an Ant task that executes single tests or directories of tests
e. Using the JunitReport task to generate HTML reports of testsuites

"Imperfect tests, run frequently, are much better than perfect tests that are never written at all." -Martin Fowler

Something about unit testing in general that really struck me recently after reading http://homepage.mac.com/hey.you/lessons.html was the fact that as developers we really do unit testing all the time. This is usually in the form, code -> add cfoutput or cftrace -> Alt+Tab to browser -> Ctrl+R to refresh, and make a visual assessment of the output. If it looks good, we go back to code -> remove or comment cfoutput or cftrace -> Alt+Tab to browser -> Ctrl+R to refresh, and make a visual assessment of the output. This is the way I was doing it for most of my career. If you think about it, there is a lot of really good information contained in this activity: (1) why was a cfoutput placed in the code?, (2) what was I looking for?, and (3) what was I expecting to see in the output? Ok, what really struck me, like a ball-peen hammer upside the head, was the fact that all this intellectual property gets thrown away when we go to production. During maintenance, I then repeat the same steps over - code, trace, view output. I'm starting to think this is a bad habit. I have to recall what I was trying to do in the code in the first place and why. With a saved unit test, which takes more time up front, I have an artifact immediately at my disposal that answers these questions and let's me know when my code breaks. It also lasts for the life of the software and serves as really good documentation.

This code illustrates that I want to see that the generated output from this component is in fact XML, JUnit XML, and HTML. I would be looking for specific test result numbers in addition to format info. This is now all preserved in code so I won't forget.

Not bad, as far as conferences go. Gary McGraw gave a spirited and poignant keynote - with the clear message of "Do Security Testing" and tell everyone around you that it is important and tell then, too, what's involved.