For object-oriented languages like Java, it makes sense to package groups of tests as the set of methods of a Java class. However, even though it is true that ColdFusion has its own approximation to objects (ColdFusion Components), I humbly submit that they are a little out of place in a tag-based, file-based, quick prototyping language. To me, it makes much more sense to have ColdFusion do the presentation logic and HTML generation, interfacing with Java objects for business logic and backend processing (also possible with ColdFusion).
I'm going to guess that most ColdFusion projects, however, do not attempt an object-oriented, properly layered design. ColdFusion is a good language to quickly throw up simple dynamic sites. Structure and layering are not its strong point. ColdFusion sites are groups of custom tags (i.e one function per file), presentation scripts, user defined functions, ColdFusion Components and included templates. A ColdFusion testing framework should be able to test all of these, and test them in a way that is natural to ColdFusion.
I chose to design ColdUnit to take advantage of this natural ColdFusion coding style. Tests are packaged as sets of files within a directory. Each file defines a unique test, although each test may contain many assertions, and thus in a sense be multiple tests. These test files are identified as test files using a naming convention: their filenames must begin with the string "test" (and, to be precise, end in ".cfm"), and they must be placed in a directory whose filename also begins with "test". They then use <CFINCLUDE>, <CFMODULE>, <CFOBJECT>, etc. to include, call, instantiate, etc. the particular piece of code you want to test, whether that be an included template, a UDF, a custom tag or a CFC.
I'm sure that, having published them on the Web, I'll have to eat some or all of these words someday soon. However, this page hopefully helps explain why ColdUnit was designed the way it was.