what do I know

After lunch we came back to Bryan Liles presentation on BDD which he retitled from “BDD with RSpec” to “BDD for Normal People”. Bryan is definitely a kindred spirit of mine, if only in his sense of humor. He was a great presenter and put a great face on the his own approach to TDD and BDD. What I liked about the presentation was his ability to bring practicality into the mix and give his audience direction and a place to start on their test driven journey. In any case, on to the topic at hand.

Brian started out describing his own journey into testing and some of the struggles involved. He pointed out that as most of us begin to integrate testing, many of us are adopting different approaches but still writing poor tests to cover poor quality code. Brian identified that tools can help us in our journey by introducing more clear test names and concepts such as context, but we still have to apply these tools more effectively. He gave the following steps as a basic guide to BDD:

• Get comfortable with the concepts in TDD.
• Make it your mission to practice TDD all of the time (even when it hurts).
• Think of your application as objects expressing behaviors.
• Create examples of those behaviors [and use them as the basis for your tests].

He expressed that TDD is painful and there is an upfront cost, but that upfront cost is migitated by the quality of the tests you produce and the less trouble you have as the software grows.

On the practical side of things, Brian, although praising what RSpec has done for testing in Ruby, suggested looking into alternatives that work a little better under the hood. He suggested sticking with Test::Unit, shoulda, and RSpec StoryRunner as he’s had the most success with this combination. Additionally, in the questions segment, Brian said he doesn’t have much faith in code coverage tools and only uses them to show a relative change in coverage to confirm that coverage has gone up or down.

Overall, I’ve got a lot of new topics to read on, and I’m sure Dan and Tyler will be happy to see me giving TDD/BDD another shot. Great work Brian!

NOTE: I forgot to mention the most important note from the entire presentation … TDD == BDD, it’s just a matter of perspective. Thanks to Dan for reminding me of this.

This session was with Paul Kenney who is now working with Adobe in their Hosted Services Group. He is also the creator of cfcUnit, so I was eager to see what the framework could do compared to our experience with cfUnit.

Paul basically described test driven development (TDD) as the incremental process of designing your unit test cases prior to writing your code. He was explicit in saying however that you should develop test cases and their corresponding code one at a time. The goal was not to spend the entire time developing a test suite that didn’t have the ability to run. He said TDD was the process of implementing the most basic functionality needed (the provided specs in most cases) to satisfy the Test (I usually call this a test method). Once you’ve completed your code base and test cases, TDD requires that you participate heavily in refactoring to seek out the following issues:

• Duplication of responsibility
• Unclear Intent (classes with low cohesion)
• Code Smell (=Intuition about your code)
• Adding relevant comments
• Indentifying if something should be a data class (which I think is what he’s calling a VO)
• Code Duplication
• Inappropriate Intimacy
• Large Classes (possibly low in terms of cohesion in which size is a potential indicator)
• Lazy Class (not sure about this one)
• Long Method (again another low cohesion issue)
• Switch Statements (possible indicator for seperation of responsibilities)
• Shotgun Surgery (code changes propagated across multiple classes, possible identification of tight coupling)

I like some of the terms he used because they’re quirky, but I didn’t see a lot of formalization in the presentation.

Paul then showed us the basics of how cfcUnit works. He has a nice test runner compared to cfUnit, but with the CFEclipse integration now, I don’t see that as a huge advantage. I also noticed that on a failure, only the failure message, default or custom, is delivered in his test runner, but no line number is available. This kinda sucks and I’m not sure cfUnit has that functionality, but it’d be nice to see. Overall, I didn’t really see a reason to switch over to cfcUnit from cfUnit at work. Pauls says now that he’s getting a lot of community support, he is going to start putting together a bunch of new resources for the API, improving support, and begin looking into what upgrades he can give the framework. I’d definitely like to see more in terms of the hacked form of annotations I’m seeing used now at the conference (idea of added extra attributes to a tag, so getMetaData() can be used during introspection on the tags).