Last night, John Mason came up to the New York ColdFusion User Group to present on unit testing in the CFCUnit framework. First, I just wanted to send out a big thanks to him for coming all the way up from Atlanta to share his expertise with us. His presentation was quite good and is available on labs.fusionlink.com. While I have not had a chance to look at the resources he has posted online, apparently it contains quite in-depth coverage on setting up the CFCUnit framework and how to leverage it and ANT-automate it effectively within CFEclipse.
| || || |
| || |
| || || |
Unit testing is something that is particularly interesting to me because I am now at a point where I'm actively learning more about object oriented programming and the use of it within ColdFusion. I have watched presentations on unit testing before, but sadly enough, it was only recently that I realized that CFCUnit (and unit testing in general) is really only geared towards ColdFusion components. Apparently, there are ways to unit test individual CFM templates, but where CFCUnit really excels is in its ability to exhaustively test the methods of a given CFC. I think this point is often glossed over because it is assumed that people who are interested in unit testing already understand what a "unit" is.
Anyway, the idea writing test cases as you write your components is a bit paradigm shift for me. While I do a great deal of my testing during development - I'm very much a "code a bit, test a bit" programmer - all of my testing is lightly structured and manual. This method works decently on small sized projects, but for larger projects, I can really see how automated testing saves you in the long run when it comes to regression testing and general maintenance of software.
In addition to unit testing CFCs, John briefly covered user interface testing with Selenium. During the presentation, I was not exactly sure if Selenium was plugging into the CFCUnit framework, or whether its use was just being automated through CFEclipse and ANT. Either way, it was nice to see that someone does automated UI testing, if for no other reason than to prove to me that Selenium is worth looking into. I tried using it one time on an existing application and found it totally overwhelming. But, seeing him use it, I am convinced it's worth another look.
About The Speaker
John Mason works at FusionLink, a ColdFusion and Flex hosting company based in Atlanta, Georgia. He has been programming with ColdFusion since 1996 and Flash since 2001. John was a contributor to the CFDJ and actively posts on several ColdFusion, Flash and Flex related lists. He holds an Adobe ColdFusion Advance Certification and also MBA from Georgia Southern University. Currently, he enjoys working on his Flex certification and building beta applications in AIR.
Thanks for the review! I had a great time presenting to NYCFUG and meeting you guys. Thanks again for inviting me.
Just a couple of comments I want to add for those that run across this information. CFUnit (not to be confused with cfcUnit) has an assertion test for CF templates like to the standard *.cfm or *.cfml pages. I have not had much luck with it, but it is there if you need it. But like Ben says in this posting, these unit testing frameworks really are design for testing units (classes) and their methods which in the CF world would normally be a Coldfusion component (*.cfc page).
The Selenium stuff I showed at the end wasn't directly plugged into cfcUnit. I simply automated it's testing as well inside of my ANT scripts the same way as I would the cfcUnit tests. If you have an older site that isn't using many CFCs, the Selenium tests can still be very useful in testing your application.
All of the ANT stuff looked very cool. I am still rocking old school HomeSite 5.5 so none of that stuff comes with it. I think it's time that I make yet another attempt to switch over to the Eclipse editor.
I've really relied on CFUnit for my current project, I found it did two things for me:
1. It moved me in to test driven development, and forced me really think what I wanted each component to do, and to limit the complexity of, dependencies between my components, so I could have 'testable' code, and could test each component is isolation.
2. As I built up my test suite, my development time began to speed up considerably, because I could quickly test all my components to see the impact of a change, and if something 'broke', I 'knew' that previously tested components worked, so the problem was in the new/changed component.