Got Hard-to-Test code? We Want It!

Wednesday, March 18, 2009

Do you have CFML code that's hard to test? Maybe it's a legacy component written long before you tried out unit testing. Maybe it's something you wrote yesterday and even though you had testing on your mind, the test didn't flow out of you quite the way you hoped. Think back to some coding you've done recently. Did you have every intention of writing tests but then, when you started, said "Ahhhh, screw this", and gave up? If so... we want to hear about it! We're looking for CFCs, even CFM templates, that you think don't lend themselves to easy testing. We don't care what they do. Talk to databases? Fine. Delete 10 million files? Great! No need to give us any "setup" stuff like databases, test files, or whatever. We just want the code. Why, you ask? A few reasons. First, we're kicking into gear the development of the next gen MXUnit, and we want to get a good feel for the kinds of testing challenges people need to solve. That's longer-term. Short term: I'm presenting on designing-for-easy-testability at cfObjective this year and I'd like to dispense with the canned code and get real. I want to use real people's real code to demonstrate the techniques we've learned over the years for refactoring for easier-to-test code. Maybe you're thinking, "But I'll be embarassed." Don't be. We won't attach any names to anything. Email it to us at theguys at Thanks in advance!


Ben Margolis said...

Are you still in need of hard-to-test code? I have code that puts a lot of objects in application scope upon app startup. (They are singletons.)

billy said...

Sure! I'm sure Marc will chime in ... maybe send the details to theguys at ?

For me, this also begs the question of "How can you test an Application.cfc?"

Ben Margolis said...

Yeah it begs that question.

My problem comes down to the fact that these objects (called Aspects in my framework) are not in a hierarchy. There are a bunch of objects in application scope that may use each other. Because they are all instantiated at the application start, wherever you are in the app you know you can use any one of them.

Let's say you have a Contacts data access object and a Exporter object that writes files with all your contacts. In Exporter.cfc you can have a method writeContactFile() which calls APPLICATION.Contacts.getAll() ...

How do you unit test writeContactFile() in Exporter.cfc ?

In your unit test CFC you probably have to execute whatever it is that your code does on application start prior to any tests? I think this is where it got messy and I hit a wall.