I've just spent the better part of an hour trying to figure out why my cfcUnit tests for this project I'm working on suddenly stopped working....stopped working as in DOA.  No errors, no failures, no screen output, NADA.  All the tests were running fine (and passing) yesterday when I left the office so I was quite puzzled. On top of that my processor pegged at 100% utilization and the fan RPMs on my laptop started their slow climb toward jet engine speeds.

I had renamed some CFCs this morning as part of changing my mind on how I was going to approach something so I went into the test case files and made the necessary corrections and ran my tests to make sure I'd gotten everything.  I expected to see maybe an error or two saying that it couldn't find a particular CFC which would have meant that I missed renaming one somewhere in the code (hey that's what unit tests are for right?).  Insead, I was greated by a blank white browser screen.

Last week I had installed the latest version of CFCDoc and was prowling through the output generated by it for the cfcUnit framework.  I was looking at the framework.assert class and noticed an assertion named assertClass.  I thought it would be handy to use that to be able to test to ensure that the CFC is returning the appropriate class on instantiation (again, to help me catch typos etc in class names). That assert statement looks something like this:

<cfset assertClass("path.to.someComponent",
    "Object someComponent is not of the correct class.")>

What I have since learned is, if you have the incorrect text name of the full dot-notated path to the CFC (the first argument in the assertClass method call above), cfcUnit just hangs.  I'm not sure how much use to me this is going to be if I can only ever get a true result output to the screen (vs no output at all on my entire test suite).

I thought maybe that my JRE version for CF8 was affecting it (see Sean Corfield's post from December 5, 2007) so I verified that CF8 was running on 1.6 and updated the jvm.config file to point to the 1.5 JRE.  Same result.

In the end the fix involved correcting the path in the assert statement and my cfcUnit tests were all hunky-dory again.