http://seancorfield.github.io for newer blog posts." />

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

MXUnit

March 8, 2008 · 13 Comments

As many folks know, I've long been an advocate of Paul Kenney's cfcUnit unit testing framework. I felt it offered the most solid code base and the best all-round feature set in a package that was idiomatic for ColdFusion developers. Unfortunately, the website has not been updated in over 18 months and, although a new build was made available on sourceforge.net a year ago (1.2.0 Beta 1), there has been no progress on integration with Eclipse. 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.The documentation is still somewhat thin, albeit somewhat better than cfcUnit, but it has a rock solid ant integration and a very slick Eclipse plugin, as well as a very convenient way to automatically run any unit tests found within an entire directory tree. I've switched. What was involved in switching from cfcUnit to MXUnit?
  • A global find'n'replace to change org.cfcunit.framework.TestCase to mxunit.framework.TestCase.
  • Global find'n'replaces to change assertEquals{String|Number|Struct}( etc to assertEquals( - MXUnit uses a generic assertion rather than type-specific assertions.
  • Dropping the test suite objects - MXUnit runs all tests in a directory or you can elect to run a specific test so it does not (currently) support test suite objects
The loss of test suites is somewhat annoying but the directory test runner approach mostly makes up for that - it just means a change to how I deal with blocks of tests. The output from MXUnit is very nice, based on ExtJS (2.0), and the ant integration support JUnit style reports as well as basic test execution. The Eclipse plugin really is amazing. It can search your entire project for test cases and it allows you to run all tests or just re-run previously failed tests. You can also jump from any failure to the source of the failing test by double-clicking the line in the error report window. Downsides? The lack of support for test suites, mentioned above, because I organized all of my unit testing into suites. I'm so used to cfcUnit - and I believe CFUnit supports test suites too - and this was a big change to my test organization. The MXUnit team are considering adding something in this area. Tests must be run from a web-accessible CFML or CFC file. cfcUnit's test runner allows you to run any test case CFC, regardless of its location. MXUnit expects you to run a test case CFC by invoking a method on it - so it must be web-accessible. The MXUnit team is considering enhancing the test runner to support CFCs outside the webroot (you can use a directory test runner in its place right now but it's not as clean, in my opinion). There also appear to be a few bugs in how assertEquals() handles certain types of data as well as a couple of bugs in how the directory test runner locates tests. The MXUnit team have been very responsive to my suggestions and requests so far so I expect these will get resolved as more people start using the framework. Of course the basic problem here is that not enough CFers are even doing unit testing right now...

Tags: coldfusion · tdd

13 responses so far ↓

  • 1 Jim Priest // Mar 8, 2008 at 5:22 PM

    Bill Shelton just gave a great preso on CFMeetup "Unit Testing w/MXUnit - Jump Start"...

    http://experts.acrobat.com/p89509280/

  • 2 Peter J. Farrell // Mar 8, 2008 at 6:29 PM

    Recently Kurt Wiersma convinced me of using MXUnit and we have started to use MXUnit for unit tests for Mach-II 1.6. The Eclipse plugin is neat (once you get it working -- there are a few configuration issues). MXUnit is definitely something to look at.
  • 3 Mike Harman // Mar 8, 2008 at 9:52 PM

    I attended Bill's CFMeetup preso and was so impressed that I am reviewing it and seriously considering switching.
  • 4 Rachel Maxim // Mar 9, 2008 at 7:35 AM

    So is Eclipse plugin the main reason for switching? Or because MXUnit is being more actively developed?
  • 5 Kurt Wiersma // Mar 9, 2008 at 8:25 AM

    I converted from CFCUnit to MXUnit about a month ago and have not looked back. Aside from the Directory test runner, the killer feature for me was to be able to show output in the test runner. They have slick debug() method you can call that will do a cfdump on whatever you pass to it. You can also do a cfoutput inside a test. While I am getting my tests working this is a life saver to be able to see what is getting returned. It is also helpful to verify large object graphs when I am created a remote service to be called by flex.
  • 6 Sean Corfield // Mar 9, 2008 at 10:51 AM

    @Rachel, both. The ant integration is slicker too.
  • 7 Rachel // Mar 9, 2008 at 11:43 AM

    Sounds really cool. Thanks for the add'l advice guys!
  • 8 Sean Corfield // Mar 9, 2008 at 3:38 PM

    I forgot another minor find'n'replace change: in cfcUnit, your setUp() and tearDown() methods can be private because they are public in the base class and they are still callable through the base class. In MXUnit, your setUp() and tearDown() methods *must* be public otherwise the framework will not run them.
  • 9 Ryan McIlmoyl // Mar 10, 2008 at 5:40 AM

    I've been using CFUnit for a while and really been digging it. Is MXUnit that much better?
  • 10 Aaron Longnion // Mar 10, 2008 at 6:33 AM

    Ditto on migrating to MXUnit. I'm very exciting the folks at MXUnit are taking the time/effort to do a CF unit testing framework right, and to put a *sustained* effort together for the benefit of the community, including some CFMeetup presos, etc.

    FYI - to those of us migrating from CFUnit to MXUnit: you simply have to copy your CFUnit test CFC files to a MXUnit directory with the MXUnit-style run.cfm, and then update the Extends as Sean points out above, and then add cfset setTestStyle("cfunit") somewhere in your Test CFCs (see the sample at /mxunit/PluginDemoTests/SubDir/CFUnitStyleTests.cfc). Voila... easy and quick transition. ;-)
  • 11 Ryan Stewart // Mar 28, 2008 at 8:08 AM

    Did you never user cfcunit assertRegexMatch()? How did you handle the these if you did?
  • 12 kevin // Jan 5, 2009 at 7:11 AM

    How do you get your mach-ii application to work with mxunit. I tried doing this with cfcunit before but failed
  • 13 Sean Corfield // Jan 5, 2009 at 8:17 AM

    @Kevin, I'm not sure what you mean. MXUnit is a unit testing framework - you use it to test components in isolation from an application framework. I suggest you join the MXUnit mailing list (if you're not already on it) and ask folks there about how best to use MXUnit.

Leave a Comment

Leave this field empty