The other day I posted about using the test-first approach to fix a bug I found in the MXUnit Eclipse plugin. That walkthrough is here, although it doesn't have all the pretty pictures. Here's another walkthrough along the same lines, except this one demonstrates using test-first on new functionality. And it has pretty pictures. With this one, I tried to demonstrate what I was thinking as I was coding and testing. So if you're getting started with unit testing CF and want to get in someone's head as they do it, here's one example. Enjoy.

I found a bug the other night in the MXUnit eclipse plugin. I thought documenting my approach to fixing that bug might be useful as a case study in bug fixing using a test-driven approach. In this case study, I walk through step by step what I did to fix the bug and prove it was fixed. What I like about this is that it's a real-world example. It's not canned. Canned stuff can take on an air of "oh, my, look how neat and tidy this all is!". Don't get caught up in the particulars of the bug. They're not important. The important part is the method. So, here it is. Enjoy.

Please join me in welcoming Amir Saheli as the newest MXUnit dude. Amir has oodles of software and product development experience and will be of tremendous value to the team. At this point, however, his libation and tobacco preferences are not fully understood. I suspect that this will not be an issue, as I personally have seen him smiling just a little too much from time to time. Other esteemed team members (vice corrections welcome): Raj Vijayaraman (Coffee, coffee, and espresso, and occasional green tea in large doses) Mike Rankin (Jolt++, Nyquil) Marc Esher (Glen[a-zA-Z]*, and anything from Havana) Bill(y) Shelton (too old for that shit)

As Mike Rankin wrote yesterday, a modified version of CFCBlaster is slated to be used as the underlying test generator in MXUnit. It's not in the download yet but will be after we get it incorporated fully. If you're a subversion user, you can get all the latest mxunit code from https://mxunit.googlecode.com/svn/ (point to mxunit/trunk). The great thing about CFCBlaster is that it's XSLT-based and thus highly configurable. Also, tonight I put out an update to the MXUnit eclipse plugin for unit testing in the IDE. This release includes a very small bug fix (see explanation in the comments to this post). But the biggest change is that the view's two main panels are now resizable. This has been a long time coming, and its absence has annoyed me since the beginning. Bill promised me a box of Cohibas (right, Bill?) if I'd get this feature in sometime soon. Documentation for installing the framework and the plugin is right on the front page Enjoy.

I added the cfcBlaster derivative to the mxunit trunk. Take a look and see if it's heading where you want. Most of the potential at this point lies in making the templates more robust. Right now there are two very basic ones in there that are almost identical. The only difference is that one will create failures so you can dig into the tests that need attention and the other lets the tests succeed. WARNING: You will blow away any tests you have already written if you use this thing indiscriminately. Back up your existing tests if you care about them. You want to use this thing to jump start a bunch of testing stubs if you have a project already in progress and you need to catch up. It really doesn't work if you're doing TDD the way it's supposed to be done since it needs your components to build the test files. Ya gotta start somewhere, though.

This was a great weekend for me and I think for our little project. First, Mike Henke helped a ton in ferreting out some issues with the framework on Linux. Thanks, Mike! What I learned was that component names are case sensitive on Linux. Having programmed nothing but perl on linux, I never knew this was the case. It's perfectly sensible... I just never knew it. At risk of looking like a total n00b, there's something else I didn't know about CF, or else I knew it but quickly forgot it since it's not something I've ever had a reason to do. Prepare to laugh. I did not know that a subclass of a component could override a private method with a public one and then call that private method via super(). Didn't know it. I do a lot of java programming, and you can't do it in Java. I assumed you couldn't in CF. I'm not talking about the super part. I'm talking about the private part. In Java, private is private and you ain't seein it if you ain't the object. There is no inheritance. Your children starve. But you know what they say about assuming... Anyway, thanks to Sean Corfield for showing me the light. The net result of this was an additional bit of functionality in MXUnit with respect to testing private methods. Now, it supports two styles: one is a direct function injection into a precreated object. The other is the creation of a new object that extends the object in question and overrides the private function under test. The differences in approach are discussed here: http://mxunit.org/doc/index.cfm?doc=testprivate Regardless of the approach one takes (the code is virtually identical in either case), it should lead to easier testing of private methods without the maintenance headaches of a more traditional approach. So, it was a great weekend: learned new things, improved the framework, improved the documentation, and drank more Dalwhinnie 15. If only it weren't too damn cold outside for a Fuente.

We got some snow last night. The drive home sucked, but making big snowballs with my daughter made the snow worthwhile. For scale, here's the snowman we built. he's between 3 and 4 feet tall: and here are the snowballs:

No, I'm serious. This is just a test post to try out some of the stuff on blogger. I know. Dudes like me are supposed to be all techno and bloggy and whatnot. Should've been blogging since 1994 when it all started. I know. But hey, I'm reluctant. I'm busy. And besides, who the hell cares? I had about 5 minutes of fun today puzzling over some puzzling (duh) thing. Here's what the MXUnit view is supposed to look like in eclipse: But When I opened up a test file, right clicked, hit "run mxunit test", nothing. just dead air. So I'm like "helloooooo McFly". I pop open the error view and sure enough, the dreaded "Unhandled event loop exception". WTF? I've been using this plugin way too long to get stuff like that. The error: NoClassDefFound javax.blah.SomethingOrOther.That.Axis.Depends.On I open up my mxunit debug launcher. a new eclipse instance pops up. All works fine. Now I'm getting tight. Like a retard, I try 5 more times. Same error. So I'm thinking, "I've seen this sort of thing before". Classes just go off missing, straight up punk out and split. Like, "see ya, douche, i'm outta here". I still get this in a spring app of mine from time to time. It's almost like the class is garbage collected right before my eyes or something. hmmmmm..... What's changed recently? Well... the only thing I can remember changing was that I added a plugin for watching the eclipse heap size, and it puts this little garbage collector button down in the trim and you just wanna click it cause you like to see the numbers drop. i clicked it like 10 times today (i was bored). Could it really be possible that it just swiped a class from the classloader? Noooo. No way. So what do I do? I get in touch with my inner IT guy. I ask "What would the IT guy do? (WWITGD). I know what he'd do. Restart. Done. Fixed. So anyway. I wonder what that image i uploaded will look like. I got some queer ajax screen from blogger when I was uploading the file. Little bastard just sitting there spinning saying "we're ftping your file". Oh yeah? Takes 10 minutes to ftp an image, eh? I go back to this here blog screen and there's the image, in the editor. Oi. See... told you this was definitely not worth your time. you can't say I didn't warn you. And although poor you just spent 3 minutes reading this drivel, I'm gonna go have a Dalwhinnie 15. In 2 minutes, you'll still be thinking "what the F did I just waste my time on that for" and I'll be thinking "Whoever started the Dalwhinnie distillery surely sits at the right hand of the Father, for he has brought glory unto this world". Cheers!

I caught this recently and enjoyed it. It's a presentation on unit testing from the railsenvy dude (aka Gregg Pollack, aka the dude made infamous in the cf world with this hilarious video). I know, I know. NO ONE actually watches any videos anyone posts on their blog with "hey, you should check this out!". What I like about this presentation is that Gregg's philosophy on unit testing is in line with Bill's and mine: no preaching. no religion. no zealotry. no "if you aren't testing, you aren't a programmer" nonsense. Our philosophy to date has been, simply, here's a framework for testing that we hope makes testing easier. Here's some advice, tutorials, case studies, etc. Here's a plugin for eclipse so you don't have to drop out of the IDE if you don't want to. If you manage to get started (that's the thing, really.... just start), we think you'll find it's not so bad. I find the perceptions of unit testing are similar to the perceptions of excercise, cough medicine, flu shots, and seat belts: You know you should, but... [insert reason why not here]? And so that's what I like about Rails dude's video: he talks about why he loves to test. That's all. Just a programmer who loves what he does. I dig that.

I decided to make a case study out of the development for Issue 48 i.e. making private methods testable. I took screenshots at every step of the way and plan to document it all. I think it'll provide insights into the tiny little iterations and sometimes inconveniences one encounters when unit testing; it'll also show how to easily overcome them. Just as importantly, it should demonstrate the tremendous benefits of unit testing. I find that what I like about mxunit is that for the most part it doesn't make it too tough to see the information I need to see when I'm developing. I like cfdump. I like seeing the data I'm dealing with (does the string have periods or back slashes? what keys are in the getMetadata() struct for this here function, anyway?) But more on that later. Oh, and how to test private methods, i.e. private functions, i.e. <cffunction .... access="private"> (or access="package")? That's pretty easy. Well, now it's easy, anyway.

... to start. So that's my intention. To that poor bastard who "reached the end of the internet", be warned. The most I can say right now is that what I put here, assuming I follow through, will be at least as useful as the drivel in the average teenage girl IM.

Check out the new tutorials and documentation at: http://mxunit.org/doc/index.cfm Comments and suggestions are always welcome! Enjoy, bill