Switching From cfcUnit to MXUnit
By: Sean Corfield
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…