The guys put out Episode 5 this week after an an extended break. In this episode, they addressed the question “What processes/practices/tools do you use to help ensure software integrity?”. Brian did most of the talking, and threw around his favorite phrase several times. I can see it now… Brian’s at a cocktail party, the chicks are dancin’, and he’s all “Hey Baby! You got some mad cyclomatic complexity goin’ on!”

OK, OK. All snarkiness aside, this week’s episode touched on three subjects near and dear to me: testing, ANT, and continuous integration. I was thrilled that they spent so much time covering these topics. As they said, each one could fill up a podcast on its own, and I appreciate their honesty here… you can’t just listen to an hour long podcast and be Jonny Test. It takes a long time, and a lot of practice, to get there. Still, the more people out there saying “you need to test, people”, the better. Introductions to the concept, benefits, and resources are never a bad thing, and I think Brian covered these topics as well as can be expected in 60 minutes.

And they gave MXUnit a lot of lovin’ during the show. So, gents, thanks for that! But it’s not gonna get you out of some gentle ribbing. Here goes:

Finger on the Pulse

Your intrepid reporter (uh, me) must confess to some surprise during the first few minutes of the episode. Here are 3 dudes who have been programming in CF for years, who have a frickin’ podcast about CF, but who talked about the CFMeetup almost as if it was some alien thing. Guys… Charlie’s been hosting guest speakers for years on the CFMeetup. The sessions are recorded so you can get them after-the-fact at http://carehart.org/ugtv. This is a tremendously valuable resource for CFers, and I damn near have a hard time believing that people as involved with CF such as yourselves wouldn’t have been on top of that like white on rice.

What’s worrisome to me about this is that if you dudes don’t know about the CFMeetup and carehart.org in general, what’s that mean for the great masses of CF developers who aren’t even as active as you all are, who don’t do a CF podcast? And more importantly, how do we get the word out to more developers about the CFMeetup awesomeness? 

Aside: When I started learning Eclipse plugin development, I struggled with beginner-ish things even after reading a book on the topic. Most newsgroup questions were met with “look at the source”. Fair enough, but… what I really wanted was the answer to “What are the XX most important things a newbie should know about plugin development?”. I wonder how we get the answers to those questions out to new and old CFers alike… it’s not just about code, but also about resources. I wonder how we can all do a better job of connecting developers to the community. We spend so much time worrying about how to evangelize outside the community, but it seems that we need to start thinking about how to connect the people in the community to the excellent available resources that exist that can help make their lives easier. End Aside.

And what about other ways of keeping a finger on the pulse of CF? Having helpful blogs on the radar, knowing helpful people to contact when the going gets rough, etc. I’m in no way suggesting that it’s one’s professional duty to be reading blogs all day, interacting on twitter for hours, attending all the CFMeetups (I rarely do… I catch the ones that interest me at more convenient times, via the recordings) or otherwise engaging in annoying starry-eyed CF fanboi-dom. Simply, I hope that as CF podcasters, you fine fellows can grow into your role as emissaries of our small-but-growing(-at-least-according-to-Adobe) community. When I listen to podcasts for other technologies, I do so because I expect the people behind the mics to be completely in tune with the community. As TWiCF, people are going to expect that of you, and I know you want to deliver.

While I’m heaping un-asked-for responsibilities on you, I think it’s also important that you keep on talking about .NET and the things you are working on outside of CF. Lord knows the CF community is an insular one, and more reasons to lift the head up and look around are welcome.

Get involved. You’ll be better for it, and so will we.

With that ticklish ribbing out of the way, let’s move on.

Unit Testing vs. TDD

Brian spent a lot of time discussing programmatic testing. Good on you, Brian. Clearly he’s a practitioner and knows his stuff. I was also interested in hearing more about the different tools for functional testing. I sure would like to see all these tools in action… the great symphony of testing. How about it, Brian? How about a CFMeetup presentation demo-ing these functional testing tools?

Now, a nit to pick: Brian mentioned once during the episode that there was no difference between writing tests first or last. It’s my experience that there is a tremendous difference between the two. I won’t belabor the point because it’s been done to death (google it), but here’s the bottom line: writing tests first is an act of design. It damn near forces you to write testable code because from the start, you’re thinking, “How can I test this?”. It seems to me that when I write tests first, I end up approaching Uncle Bob’s SOLID principles almost naturally.  However, when I wait till afterwards to test, I miss out on that design opportunity and sometimes find that I have written less-testable code.

I will be the first to admit this is because I am not all that bright, and that other far more capable developers come by easy-to-test code quite naturally, as if the ability were bequeathed unto them by The Almighty Himself.

Furthermore, there is certainly no lack of debate around the desirability of easy-to-test code. More than a few developers believe that writing test first is a crippling exercise, atrophying the brain, because you’re thinking about testability and not the bigger picture of the system. In addition, there are those who believe that thinking about testability inevitably leads to Frankenstein, contorted designs (accessors/mutators where there otherwise wouldn’t be; reliance on non-void functions when if you weren’t testing, the function wouldn’t return void; exposing more methods as public when they should be private, etc). All fair points, and I’ll leave it to bright people to argue over while I go write code.

So: “having tests” (and running them frequently) is helpful for catching regression bugs. Writing tests first is helpful as an act of component design which – to many – leads to higher quality software.

P.S. If you’re interested in other podcasts or videos covering TDD/BDD, Hanselminutes has had a few gems. The interviews with Scott Bellware and Roy Osherove are classics. And you can’t go wrong listening to Joel and Jeff dis TDD and SOLID on the stackoverflow podcast. Finally, in the NSFW category, is Baltimore’s own, the incomparable Brian Liles.

Continuous Integration

I’ve been using the Hudson continuous integration server at work since May and am quite taken with it. I’ve written about it before so won’t belabor the point. But Brian mentioned that he’d like to hear if anyone else out there has any suggestions regarding CI. So… I do. Brian mentioned that having the build server email you on every build becomes a bit much, and I heartily agree. In fact, one of the reasons Hudson impresses me so much is its plugin ecosystem. Specifically, the ‘Extended email plugin’ is outstanding for noise reduction. If you want to read more, have at it.

Other Resources

Brian mentioned ANT several times, so I thought I’d point out Jim Priest’s excellent ANT wiki as a wonderful resource for CFers getting into ANT. In addition, for those interested in learning more about Selenium, Mike Henke has written a decent amount about it. And, finally, check out http://carehart.org/ugtv and search for both ANT and Selenium to find presentations on the topic.

Wait, what? That’s all?

This week’s TWiCF review has turned into less a review of the episode and more just a general meandering about the topics they discussed. Why is that? Well, because I don’t want to be your Cliff’s Notes. Go and download the episode and listen to it. It’s a good one!

Till Next Time

Thanks again, gents, for another enjoyable episode. I’m looking forward to the next one.

Marc, out